Merge branch 'main' into fix/missing-web-bundler-entry-point

* docs: apply style guide to TEA Lite quickstart

- Remove duplicate H1 header (frontmatter provides title)
- Remove horizontal rules throughout
- Convert Prerequisites to admonition
- Add Quick Path TL;DR admonition
- Convert Key Takeaway to tip admonition
- Convert TEA Workflows list to Quick Reference table
- Convert Troubleshooting to Common Questions FAQ format
- Rename Need Help to Getting Help section
- Remove redundant Feedback section

Also adds missing @clack/prompts dependency from upstream merge.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: spell out acronyms in TEA Lite quickstart

- MCP → Model Context Protocol
- E2E → End-to-end (also fix missing article)
- CI/CD → Continuous integration/continuous deployment
- ATDD → Acceptance Test-Driven Development
- TDD → Test-Driven Development
- NFR → non-functional requirements
- Remove inaccurate CRUD reference

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* docs: spell out TDD in ATDD link text

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Murat K Ozcan <34237651+muratkeremozcan@users.noreply.github.com>

.github/workflows/bundle-latest.yaml

@@ -10,6 +10,7 @@ permissions:
 
 jobs:
   bundle-and-publish:
+    if: ${{ false }} # Temporarily disabled while web bundles are paused.
     runs-on: ubuntu-latest
     steps:
       - name: Checkout BMAD-METHOD

.github/workflows/quality.yaml

@@ -69,6 +69,27 @@ jobs:
       - name: markdownlint
         run: npm run lint:md
 
+  docs:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup Node
+        uses: actions/setup-node@v4
+        with:
+          node-version-file: ".nvmrc"
+          cache: "npm"
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Validate documentation links
+        run: npm run docs:validate-links
+
+      - name: Build documentation
+        run: npm run docs:build
+
   validate:
     runs-on: ubuntu-latest
     steps:

.gitignore

@@ -44,22 +44,15 @@ CLAUDE.local.md
 .claude/settings.local.json
 
 # Project-specific
-_bmad-core
-_bmad-creator-tools
-flattened-codebase.xml
 *.stats.md
-.internal-docs/
-#UAT template testing output files
-tools/template-test-generator/test-scenarios/
 
 # Bundler temporary files and generated bundles
 .bundler-temp/
+web-bundles/
 
 # Generated web bundles (built by CI, not committed)
 src/modules/bmm/sub-modules/
 src/modules/bmb/sub-modules/
-src/modules/cis/sub-modules/
-src/modules/bmgd/sub-modules/
 shared-modules
 z*/
 

.husky/pre-commit

@@ -5,3 +5,16 @@ npx --no-install lint-staged
 
 # Validate everything
 npm test
+
+# Validate docs links only when docs change
+if command -v rg >/dev/null 2>&1; then
+  if git diff --cached --name-only | rg -q '^docs/'; then
+    npm run docs:validate-links
+		npm run docs:build
+  fi
+else
+  if git diff --cached --name-only | grep -Eq '^docs/'; then
+    npm run docs:validate-links
+		npm run docs:build
+  fi
+fi

.markdownlint-cli2.yaml

@@ -11,7 +11,6 @@ ignores:
   - .claude/**
   - .roo/**
   - .codex/**
-  - .agentvibes/**
   - .kiro/**
   - sample-project/**
   - test-project-install/**

README.md

@@ -7,6 +7,8 @@
 
 **Build More, Architect Dreams** — An AI-driven agile development framework with 21 specialized agents, 50+ guided workflows, and scale-adaptive intelligence that adjusts from bug fixes to enterprise systems.
 
+**100% free and open source.** No paywalls. No gated content. No gated Discord. We believe in empowering everyone, not just those who can pay.
+
 ## Why BMad?
 
 Traditional AI tools do the thinking for you, producing average results. BMad agents act as expert collaborators who guide you through structured workflows to bring out your best thinking.
@@ -60,10 +62,20 @@ This analyzes your project and recommends a track:
 ## Community
 
 - [Discord](https://discord.gg/gk8jAdXWmj) — Get help, share ideas, collaborate
-- [YouTube](https://www.youtube.com/@BMadCode) — Video tutorials and updates
+- [YouTube](https://www.youtube.com/@BMadCode) — Tutorials, master class, and podcast (launching Feb 2025)
 - [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) — Bug reports and feature requests
 - [Discussions](https://github.com/bmad-code-org/BMAD-METHOD/discussions) — Community conversations
 
+## Support BMad
+
+BMad is free for everyone — and always will be. If you'd like to support development:
+
+- ⭐ [Star us on GitHub](https://github.com/bmad-code-org/BMAD-METHOD/) — Helps others discover BMad
+- 📺 [Subscribe on YouTube](https://www.youtube.com/@BMadCode) — Master class launching Feb 2026
+- ☕ [Buy Me a Coffee](https://buymeacoffee.com/bmad) — Fuel the development
+- 🏢 Corporate sponsorship — DM on Discord
+- 🎤 Speaking & Media — Available for conferences, podcasts, interviews (Discord)
+
 ## Contributing
 
 We welcome contributions! See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.

SECURITY.md

@@ -0,0 +1,85 @@
+# Security Policy
+
+## Supported Versions
+
+We release security patches for the following versions:
+
+| Version | Supported          |
+| ------- | ------------------ |
+| Latest  | :white_check_mark: |
+| < Latest | :x:               |
+
+We recommend always using the latest version of BMad Method to ensure you have the most recent security updates.
+
+## Reporting a Vulnerability
+
+We take security vulnerabilities seriously. If you discover a security issue, please report it responsibly.
+
+### How to Report
+
+**Do NOT report security vulnerabilities through public GitHub issues.**
+
+Instead, please report them via one of these methods:
+
+1. **GitHub Security Advisories** (Preferred): Use [GitHub's private vulnerability reporting](https://github.com/bmad-code-org/BMAD-METHOD/security/advisories/new) to submit a confidential report.
+
+2. **Discord**: Contact a maintainer directly via DM on our [Discord server](https://discord.gg/gk8jAdXWmj).
+
+### What to Include
+
+Please include as much of the following information as possible:
+
+- Type of vulnerability (e.g., prompt injection, path traversal, etc.)
+- Full paths of source file(s) related to the vulnerability
+- Step-by-step instructions to reproduce the issue
+- Proof-of-concept or exploit code (if available)
+- Impact assessment of the vulnerability
+
+### Response Timeline
+
+- **Initial Response**: Within 48 hours of receiving your report
+- **Status Update**: Within 7 days with our assessment
+- **Resolution Target**: Critical issues within 30 days; other issues within 90 days
+
+### What to Expect
+
+1. We will acknowledge receipt of your report
+2. We will investigate and validate the vulnerability
+3. We will work on a fix and coordinate disclosure timing with you
+4. We will credit you in the security advisory (unless you prefer to remain anonymous)
+
+## Security Scope
+
+### In Scope
+
+- Vulnerabilities in BMad Method core framework code
+- Security issues in agent definitions or workflows that could lead to unintended behavior
+- Path traversal or file system access issues
+- Prompt injection vulnerabilities that bypass intended agent behavior
+- Supply chain vulnerabilities in dependencies
+
+### Out of Scope
+
+- Security issues in user-created custom agents or modules
+- Vulnerabilities in third-party AI providers (Claude, GPT, etc.)
+- Issues that require physical access to a user's machine
+- Social engineering attacks
+- Denial of service attacks that don't exploit a specific vulnerability
+
+## Security Best Practices for Users
+
+When using BMad Method:
+
+1. **Review Agent Outputs**: Always review AI-generated code before executing it
+2. **Limit File Access**: Configure your AI IDE to limit file system access where possible
+3. **Keep Updated**: Regularly update to the latest version
+4. **Validate Dependencies**: Review any dependencies added by generated code
+5. **Environment Isolation**: Consider running AI-assisted development in isolated environments
+
+## Acknowledgments
+
+We appreciate the security research community's efforts in helping keep BMad Method secure. Contributors who report valid security issues will be acknowledged in our security advisories.
+
+---
+
+Thank you for helping keep BMad Method and our community safe.

docs/_STYLE_GUIDE.md

@@ -1,88 +1,28 @@
-# Documentation Style Guide
+---
+title: "Documentation Style Guide"
+---
 
-Internal guidelines for maintaining consistent, high-quality documentation across the BMad Method project. This document is not included in the Starlight sidebar — it's for contributors and maintainers, not end users.
+This project adheres to the [Google Developer Documentation Style Guide](https://developers.google.com/style) and uses [Diataxis](https://diataxis.fr/) to structure content. Only project-specific conventions follow.
 
-## Quick Principles
+## Project-Specific Rules
 
-1. **Clarity over brevity** — Be concise, but never at the cost of understanding
-2. **Consistent structure** — Follow established patterns so readers know what to expect
-3. **Strategic visuals** — Use admonitions, tables, and diagrams purposefully
-4. **Scannable content** — Headers, lists, and callouts help readers find what they need
+| Rule | Specification |
+|------|---------------|
+| No horizontal rules (`---`) | Fragments reading flow |
+| No `####` headers | Use bold text or admonitions instead |
+| No "Related" or "Next:" sections | Sidebar handles navigation |
+| No deeply nested lists | Break into sections instead |
+| No code blocks for non-code | Use admonitions for dialogue examples |
+| No bold paragraphs for callouts | Use admonitions instead |
+| 1-2 admonitions per section max | Tutorials allow 3-4 per major section |
+| Table cells / list items | 1-2 sentences max |
+| Header budget | 8-12 `##` per doc; 2-3 `###` per section |
 
-## Validation Steps
-
-Before submitting documentation changes, run these checks from the repo root:
-
-1. **Fix link format** — Convert relative links (`./`, `../`) to site-relative paths (`/path/`)
-   ```bash
-   npm run docs:fix-links            # Preview changes
-   npm run docs:fix-links -- --write # Apply changes
-   ```
-
-2. **Validate links** — Check all links point to existing files
-   ```bash
-   npm run docs:validate-links            # Preview issues
-   npm run docs:validate-links -- --write # Auto-fix where possible
-   ```
-
-3. **Build the site** — Verify no build errors
-   ```bash
-   npm run docs:build
-   ```
-
-## Tutorial Structure
-
-Every tutorial should follow this structure:
-
-```
-1. Title + Hook (1-2 sentences describing the outcome)
-2. Version/Module Notice (info or warning admonition as appropriate)
-3. What You'll Learn (bullet list of outcomes)
-4. Prerequisites (info admonition)
-5. Quick Path (tip admonition - TL;DR summary)
-6. Understanding [Topic] (context before steps - tables for phases/agents)
-7. Installation (if applicable)
-8. Step 1: [First Major Task]
-9. Step 2: [Second Major Task]
-10. Step 3: [Third Major Task]
-11. What You've Accomplished (summary + folder structure if applicable)
-12. Quick Reference (commands table)
-13. Common Questions (FAQ format)
-14. Getting Help (community links)
-15. Key Takeaways (tip admonition - memorable points)
-```
-
-Not all sections are required for every tutorial, but this is the standard flow.
-
-## Visual Hierarchy
-
-### Avoid
-
-| Pattern | Problem |
-|---------|---------|
-| `---` horizontal rules | Fragment the reading flow |
-| `####` deep headers | Create visual noise |
-| **Important:** bold paragraphs | Blend into body text |
-| Deeply nested lists | Hard to scan |
-| Code blocks for non-code | Confusing semantics |
-
-### Use Instead
-
-| Pattern | When to Use |
-|---------|-------------|
-| White space + section headers | Natural content separation |
-| Bold text within paragraphs | Inline emphasis |
-| Admonitions | Callouts that need attention |
-| Tables | Structured comparisons |
-| Flat lists | Scannable options |
-
-## Admonitions
-
-Use Starlight admonitions strategically:
+## Admonitions (Starlight Syntax)
 
 ```md
 :::tip[Title]
-Shortcuts, best practices, "pro tips"
+Shortcuts, best practices
 :::
 
 :::note[Title]
@@ -90,7 +30,7 @@ Context, definitions, examples, prerequisites
 :::
 
 :::caution[Title]
-Caveats, potential issues, things to watch out for
+Caveats, potential issues
 :::
 
 :::danger[Title]
@@ -98,82 +38,19 @@ Critical warnings only — data loss, security issues
 :::
 ```
 
-### Standard Admonition Uses
+### Standard Uses
 
-| Admonition | Standard Use in Tutorials |
-|------------|---------------------------|
-| `:::note[Prerequisites]` | What users need before starting |
-| `:::tip[Quick Path]` | TL;DR summary at top of tutorial |
-| `:::caution[Fresh Chats]` | Context limitation reminders |
+| Admonition | Use For |
+|------------|---------|
+| `:::note[Prerequisites]` | Dependencies before starting |
+| `:::tip[Quick Path]` | TL;DR summary at document top |
+| `:::caution[Important]` | Critical caveats |
 | `:::note[Example]` | Command/response examples |
-| `:::tip[Check Your Status]` | How to verify progress |
-| `:::tip[Remember These]` | Key takeaways at end |
 
-### Admonition Guidelines
+## Standard Table Formats
 
-- **Always include a title** for tip, info, and warning
-- **Keep content brief** — 1-3 sentences ideal
-- **Don't overuse** — More than 3-4 per major section feels noisy
-- **Don't nest** — Admonitions inside admonitions are hard to read
+**Phases:**
 
-## Headers
-
-### Budget
-
-- **8-12 `##` sections** for full tutorials following standard structure
-- **2-3 `###` subsections** per `##` section maximum
-- **Avoid `####` entirely** — use bold text or admonitions instead
-
-### Naming
-
-- Use action verbs for steps: "Install BMad", "Create Your Plan"
-- Use nouns for reference sections: "Common Questions", "Quick Reference"
-- Keep headers short and scannable
-
-## Code Blocks
-
-### Do
-
-```md
-```bash
-npx bmad-method install
-```
-```
-
-### Don't
-
-````md
-```
-You: Do something
-Agent: [Response here]
-```
-````
-
-For command/response examples, use an admonition instead:
-
-```md
-:::note[Example]
-Run `workflow-status` and the agent will tell you the next recommended workflow.
-:::
-```
-
-## Tables
-
-Use tables for:
-- Phases and what happens in each
-- Agent roles and when to use them
-- Command references
-- Comparing options
-- Step sequences with multiple attributes
-
-Keep tables simple:
-- 2-4 columns maximum
-- Short cell content
-- Left-align text, right-align numbers
-
-### Standard Tables
-
-**Phases Table:**
 ```md
 | Phase | Name | What Happens |
 |-------|------|--------------|
@@ -181,7 +58,8 @@ Keep tables simple:
 | 2 | Planning | Requirements — PRD or tech-spec *(required)* |
 ```
 
-**Quick Reference Table:**
+**Commands:**
+
 ```md
 | Command | Agent | Purpose |
 |---------|-------|---------|
@@ -189,63 +67,277 @@ Keep tables simple:
 | `*prd` | PM | Create Product Requirements Document |
 ```
 
-**Build Cycle Table:**
-```md
-| Step | Agent | Workflow | Purpose |
-|------|-------|----------|---------|
-| 1 | SM | `create-story` | Create story file from epic |
-| 2 | DEV | `dev-story` | Implement the story |
+## Folder Structure Blocks
+
+Show in "What You've Accomplished" sections:
+
+````md
+```
+your-project/
+├── _bmad/                         # BMad configuration
+├── _bmad-output/
+│   ├── PRD.md                     # Your requirements document
+│   └── bmm-workflow-status.yaml   # Progress tracking
+└── ...
+```
+````
+
+## Tutorial Structure
+
+```text
+1. Title + Hook (1-2 sentences describing outcome)
+2. Version/Module Notice (info or warning admonition) (optional)
+3. What You'll Learn (bullet list of outcomes)
+4. Prerequisites (info admonition)
+5. Quick Path (tip admonition - TL;DR summary)
+6. Understanding [Topic] (context before steps - tables for phases/agents)
+7. Installation (optional)
+8. Step 1: [First Major Task]
+9. Step 2: [Second Major Task]
+10. Step 3: [Third Major Task]
+11. What You've Accomplished (summary + folder structure)
+12. Quick Reference (commands table)
+13. Common Questions (FAQ format)
+14. Getting Help (community links)
+15. Key Takeaways (tip admonition)
 ```
 
-## Lists
+### Tutorial Checklist
 
-### Flat Lists (Preferred)
+- [ ] Hook describes outcome in 1-2 sentences
+- [ ] "What You'll Learn" section present
+- [ ] Prerequisites in admonition
+- [ ] Quick Path TL;DR admonition at top
+- [ ] Tables for phases, commands, agents
+- [ ] "What You've Accomplished" section present
+- [ ] Quick Reference table present
+- [ ] Common Questions section present
+- [ ] Getting Help section present
+- [ ] Key Takeaways admonition at end
 
-```md
-- **Option A** — Description of option A
-- **Option B** — Description of option B
-- **Option C** — Description of option C
+## How-To Structure
+
+```text
+1. Title + Hook (one sentence: "Use the `X` workflow to...")
+2. When to Use This (bullet list of scenarios)
+3. When to Skip This (optional)
+4. Prerequisites (note admonition)
+5. Steps (numbered ### subsections)
+6. What You Get (output/artifacts produced)
+7. Example (optional)
+8. Tips (optional)
+9. Next Steps (optional)
 ```
 
-### Numbered Steps
+### How-To Checklist
 
-```md
-1. Load the **PM agent** in a new chat
-2. Run the PRD workflow: `*prd`
-3. Output: `PRD.md`
+- [ ] Hook starts with "Use the `X` workflow to..."
+- [ ] "When to Use This" has 3-5 bullet points
+- [ ] Prerequisites listed
+- [ ] Steps are numbered `###` subsections with action verbs
+- [ ] "What You Get" describes output artifacts
+
+## Explanation Structure
+
+### Types
+
+| Type | Example |
+|------|---------|
+| **Index/Landing** | `core-concepts/index.md` |
+| **Concept** | `what-are-agents.md` |
+| **Feature** | `quick-flow.md` |
+| **Philosophy** | `why-solutioning-matters.md` |
+| **FAQ** | `brownfield-faq.md` |
+
+### General Template
+
+```text
+1. Title + Hook (1-2 sentences)
+2. Overview/Definition (what it is, why it matters)
+3. Key Concepts (### subsections)
+4. Comparison Table (optional)
+5. When to Use / When Not to Use (optional)
+6. Diagram (optional - mermaid, 1 per doc max)
+7. Next Steps (optional)
 ```
 
-### Avoid Deep Nesting
+### Index/Landing Pages
 
-```md
-<!-- Don't do this -->
-1. First step
-   - Sub-step A
-     - Detail 1
-     - Detail 2
-   - Sub-step B
-2. Second step
+```text
+1. Title + Hook (one sentence)
+2. Content Table (links with descriptions)
+3. Getting Started (numbered list)
+4. Choose Your Path (optional - decision tree)
 ```
 
-Instead, break into separate sections or use an admonition for context.
+### Concept Explainers
 
-## Links
+```text
+1. Title + Hook (what it is)
+2. Types/Categories (### subsections) (optional)
+3. Key Differences Table
+4. Components/Parts
+5. Which Should You Use?
+6. Creating/Customizing (pointer to how-to guides)
+```
 
-- Use descriptive link text: `[Tutorial Style Guide](./tutorial-style.md)`
-- Avoid "click here" or bare URLs
-- Prefer relative paths within docs
+### Feature Explainers
 
-## Images
+```text
+1. Title + Hook (what it does)
+2. Quick Facts (optional - "Perfect for:", "Time to:")
+3. When to Use / When Not to Use
+4. How It Works (mermaid diagram optional)
+5. Key Benefits
+6. Comparison Table (optional)
+7. When to Graduate/Upgrade (optional)
+```
 
-- Always include alt text
-- Add a caption in italics below: `*Description of the image.*`
-- Use SVG for diagrams when possible
-- Store in `./images/` relative to the document
+### Philosophy/Rationale Documents
+
+```text
+1. Title + Hook (the principle)
+2. The Problem
+3. The Solution
+4. Key Principles (### subsections)
+5. Benefits
+6. When This Applies
+```
+
+### Explanation Checklist
+
+- [ ] Hook states what document explains
+- [ ] Content in scannable `##` sections
+- [ ] Comparison tables for 3+ options
+- [ ] Diagrams have clear labels
+- [ ] Links to how-to guides for procedural questions
+- [ ] 2-3 admonitions max per document
+
+## Reference Structure
+
+### Types
+
+| Type | Example |
+|------|---------|
+| **Index/Landing** | `workflows/index.md` |
+| **Catalog** | `agents/index.md` |
+| **Deep-Dive** | `document-project.md` |
+| **Configuration** | `core-tasks.md` |
+| **Glossary** | `glossary/index.md` |
+| **Comprehensive** | `bmgd-workflows.md` |
+
+### Reference Index Pages
+
+```text
+1. Title + Hook (one sentence)
+2. Content Sections (## for each category)
+   - Bullet list with links and descriptions
+```
+
+### Catalog Reference
+
+```text
+1. Title + Hook
+2. Items (## for each item)
+   - Brief description (one sentence)
+   - **Commands:** or **Key Info:** as flat list
+3. Universal/Shared (## section) (optional)
+```
+
+### Item Deep-Dive Reference
+
+```text
+1. Title + Hook (one sentence purpose)
+2. Quick Facts (optional note admonition)
+   - Module, Command, Input, Output as list
+3. Purpose/Overview (## section)
+4. How to Invoke (code block)
+5. Key Sections (## for each aspect)
+   - Use ### for sub-options
+6. Notes/Caveats (tip or caution admonition)
+```
+
+### Configuration Reference
+
+```text
+1. Title + Hook
+2. Table of Contents (jump links if 4+ items)
+3. Items (## for each config/task)
+   - **Bold summary** — one sentence
+   - **Use it when:** bullet list
+   - **How it works:** numbered steps (3-5 max)
+   - **Output:** expected result (optional)
+```
+
+### Comprehensive Reference Guide
+
+```text
+1. Title + Hook
+2. Overview (## section)
+   - Diagram or table showing organization
+3. Major Sections (## for each phase/category)
+   - Items (### for each item)
+   - Standardized fields: Command, Agent, Input, Output, Description
+4. Next Steps (optional)
+```
+
+### Reference Checklist
+
+- [ ] Hook states what document references
+- [ ] Structure matches reference type
+- [ ] Items use consistent structure throughout
+- [ ] Tables for structured/comparative data
+- [ ] Links to explanation docs for conceptual depth
+- [ ] 1-2 admonitions max
+
+## Glossary Structure
+
+Starlight generates right-side "On this page" navigation from headers:
+
+- Categories as `##` headers — appear in right nav
+- Terms in tables — compact rows, not individual headers
+- No inline TOC — right sidebar handles navigation
+
+### Table Format
+
+```md
+## Category Name
+
+| Term | Definition |
+|------|------------|
+| **Agent** | Specialized AI persona with specific expertise that guides users through workflows. |
+| **Workflow** | Multi-step guided process that orchestrates AI agent activities to produce deliverables. |
+```
+
+### Definition Rules
+
+| Do | Don't |
+|----|-------|
+| Start with what it IS or DOES | Start with "This is..." or "A [term] is..." |
+| Keep to 1-2 sentences | Write multi-paragraph explanations |
+| Bold term name in cell | Use plain text for terms |
+
+### Context Markers
+
+Add italic context at definition start for limited-scope terms:
+
+- `*Quick Flow only.*`
+- `*BMad Method/Enterprise.*`
+- `*Phase N.*`
+- `*BMGD.*`
+- `*Brownfield.*`
+
+### Glossary Checklist
+
+- [ ] Terms in tables, not individual headers
+- [ ] Terms alphabetized within categories
+- [ ] Definitions 1-2 sentences
+- [ ] Context markers italicized
+- [ ] Term names bolded in cells
+- [ ] No "A [term] is..." definitions
 
 ## FAQ Sections
 
-Use a TOC with jump links, `###` headers for questions, and direct answers:
-
 ```md
 ## Questions
 
@@ -260,88 +352,16 @@ Only for BMad Method and Enterprise tracks. Quick Flow skips to implementation.
 
 Yes. The SM agent has a `correct-course` workflow for handling scope changes.
 
-**Have a question not answered here?** Please [open an issue](...) or ask in [Discord](...) so we can add it!
+**Have a question not answered here?** [Open an issue](...) or ask in [Discord](...).
 ```
 
-### FAQ Guidelines
+## Validation Commands
 
-- **TOC at top** — Jump links under `## Questions` for quick navigation
-- **`###` headers** — Questions are scannable and linkable (no `Q:` prefix)
-- **Direct answers** — No `**A:**` prefix, just the answer
-- **No "Related Documentation"** — Sidebar handles navigation; avoid repetitive links
-- **End with CTA** — "Have a question not answered here?" with issue/Discord links
-
-## Folder Structure Blocks
-
-Show project structure in "What You've Accomplished":
-
-````md
-Your project now has:
+Before submitting documentation changes:
 
+```bash
+npm run docs:fix-links            # Preview link format fixes
+npm run docs:fix-links -- --write # Apply fixes
+npm run docs:validate-links       # Check links exist
+npm run docs:build                # Verify no build errors
 ```
-your-project/
-├── _bmad/                         # BMad configuration
-├── _bmad-output/
-│   ├── PRD.md                     # Your requirements document
-│   └── bmm-workflow-status.yaml   # Progress tracking
-└── ...
-```
-````
-
-## Example: Before and After
-
-### Before (Noisy)
-
-```md
----
-
-## Getting Started
-
-### Step 1: Initialize
-
-#### What happens during init?
-
-**Important:** You need to describe your project.
-
-1. Your project goals
-   - What you want to build
-   - Why you're building it
-2. The complexity
-   - Small, medium, or large
-
----
-```
-
-### After (Clean)
-
-```md
-## Step 1: Initialize Your Project
-
-Load the **Analyst agent** in your IDE, wait for the menu, then run `workflow-init`.
-
-:::note[What Happens]
-You'll describe your project goals and complexity. The workflow then recommends a planning track.
-:::
-```
-
-## Checklist
-
-Before submitting a tutorial:
-
-- [ ] Follows the standard structure
-- [ ] Has version/module notice if applicable
-- [ ] Has "What You'll Learn" section
-- [ ] Has Prerequisites admonition
-- [ ] Has Quick Path TL;DR admonition
-- [ ] No horizontal rules (`---`)
-- [ ] No `####` headers
-- [ ] Admonitions used for callouts (not bold paragraphs)
-- [ ] Tables used for structured data (phases, commands, agents)
-- [ ] Lists are flat (no deep nesting)
-- [ ] Has "What You've Accomplished" section
-- [ ] Has Quick Reference table
-- [ ] Has Common Questions section
-- [ ] Has Getting Help section
-- [ ] Has Key Takeaways admonition
-- [ ] All links use descriptive text
-- [ ] Images have alt text and captions

docs/_archive/customize-workflows.md

@@ -2,12 +2,13 @@
 title: "Workflow Customization Guide"
 ---
 
-
 Customize and optimize workflows with step replacement and hooks.
 
 ## Status
 
-> **Coming Soon:** Workflow customization is an upcoming capability. This guide will be updated when the feature is available.
+:::note[Coming Soon]
+Workflow customization is an upcoming capability. This guide will be updated when the feature is available.
+:::
 
 ## What to Expect
 
@@ -26,8 +27,4 @@ While workflow customization is in development, you can:
 - **Customize Agents** - Modify agent behavior using [Agent Customization](/docs/how-to/customization/customize-agents.md)
 - **Provide Feedback** - Share your workflow customization needs with the community
 
----
-
 **In the meantime:** Learn how to [create custom workflows](/docs/explanation/bmad-builder/index.md) from scratch.
-
-[← Back to Customization](/docs/how-to/customization/index.md)

docs/_archive/vendor-workflows.md

@@ -1,9 +1,8 @@
 ---
-title: "Workflow Vendoring, Customization, and Inheritance (Official Support Coming Soon)"
+title: "Workflow Vendoring, Customization, and Inheritance"
 ---
 
-
-Vendoring and Inheritance of workflows are 2 ways of sharing or reutilizing workflows - but with some key distinctions and use cases.
+Use workflow vendoring and inheritance to share or reutilize workflows across modules.
 
 ## Workflow Vendoring
 
@@ -24,7 +23,11 @@ From your modules agent definition, you would implement the menu item as follows
 
 At install time, it will clone the workflow and all of its required assets, and the agent that gets built will have an exec to a path installed in its own module. The content gets added to the folder you specify in exec. While it does not have to exactly match the source path, you will want to ensure you are specifying the workflow.md to be in a new location (in other words in this example, dev-story would not already be the path of another custom module workflow that already exists.)
 
-## Workflow Inheritance (Official Support Coming Post Beta)
+## Workflow Inheritance
+
+:::note[Coming Soon]
+Official support for workflow inheritance is coming post beta.
+:::
 
 Workflow Inheritance is a different concept, that allows you to modify or extend existing workflow.
 
@@ -36,7 +39,11 @@ Some possible examples could be:
 - Sprint Planning
 - Collaborative Brainstorming Sessions
 
-## Workflow Customization (Official Support Coming Post Beta)
+## Workflow Customization
+
+:::note[Coming Soon]
+Official support for workflow customization is coming post beta.
+:::
 
 Similar to Workflow Inheritance, Workflow Customization will soon be allowed for certain workflows that are meant to be user customized - similar in process to how agents are customized now.
 

docs/explanation/agents/barry-quick-flow.md

@@ -2,12 +2,13 @@
 title: "Quick Flow Solo Dev Agent (Barry)"
 ---
 
+Barry is the elite solo developer who takes projects from concept to deployment with ruthless efficiency — no handoffs, no delays, just pure focused development.
 
-**Agent ID:** `_bmad/bmm/agents/quick-flow-solo-dev.md`
-**Icon:** 🚀
-**Module:** BMM
-
----
+:::note[Agent Info]
+- **Agent ID:** `_bmad/bmm/agents/quick-flow-solo-dev.md`
+- **Icon:** 🚀
+- **Module:** BMM
+:::
 
 ## Overview
 
@@ -31,8 +32,6 @@ Barry is the elite solo developer who lives and breathes the BMad Quick Flow wor
 - Documentation happens alongside development, not after
 - Ship early, ship often
 
----
-
 ## Menu Commands
 
 Barry owns the entire BMad Quick Flow path, providing a streamlined 3-step development process that eliminates handoffs and maximizes velocity.
@@ -61,8 +60,6 @@ Barry owns the entire BMad Quick Flow path, providing a streamlined 3-step devel
 - **Description:** Bring in other experts when I need specialized backup
 - **Use when:** You need collaborative problem-solving or specialized expertise
 
----
-
 ## When to Use Barry
 
 ### Ideal Scenarios
@@ -81,8 +78,6 @@ Barry owns the entire BMad Quick Flow path, providing a streamlined 3-step devel
 - **Proof of Concepts** - Rapid prototyping with production-quality code
 - **Performance Optimizations** - System improvements and scalability work
 
----
-
 ## The BMad Quick Flow Process
 
 Barry orchestrates a simple, efficient 3-step process:
@@ -180,8 +175,6 @@ flowchart LR
 - Security considerations
 - Maintainability and documentation
 
----
-
 ## Collaboration with Other Agents
 
 ### Natural Partnerships
@@ -201,8 +194,6 @@ In party mode, Barry often acts as:
 - **Performance Optimizer** - Ensuring scalable solutions
 - **Code Review Authority** - Validating technical approaches
 
----
-
 ## Tips for Working with Barry
 
 ### For Best Results
@@ -228,8 +219,6 @@ In party mode, Barry often acts as:
 4. **Over-planning** - I excel at rapid, pragmatic development
 5. **Not Using Party Mode** - Missing collaborative insights for complex problems
 
----
-
 ## Example Workflow
 
 ```bash
@@ -306,35 +295,34 @@ Implement OAuth 2.0 authentication with JWT tokens and role-based access control
 - [ ] Given admin role, when accessing admin endpoint, then allow access
 ```
 
----
+## Common Questions
 
-## Related Documentation
+- [When should I use Barry vs other agents?](#when-should-i-use-barry-vs-other-agents)
+- [Is the code review step mandatory?](#is-the-code-review-step-mandatory)
+- [Can I skip the tech spec step?](#can-i-skip-the-tech-spec-step)
+- [How does Barry differ from the Dev agent?](#how-does-barry-differ-from-the-dev-agent)
+- [Can Barry handle enterprise-scale projects?](#can-barry-handle-enterprise-scale-projects)
 
-- **[Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md)** - Getting started with BMM
-- **[Agents Guide](/docs/explanation/core-concepts/agent-roles.md)** - Complete agent reference
-- **[Four Phases](/docs/explanation/architecture/four-phases.md)** - Understanding development tracks
-- **[Workflow Implementation](/docs/how-to/workflows/run-sprint-planning.md)** - Implementation workflows
-- **[Party Mode](/docs/explanation/features/party-mode.md)** - Multi-agent collaboration
+### When should I use Barry vs other agents?
 
----
+Use Barry for Quick Flow development (small to medium features), rapid prototyping, or when you need elite solo development. For large, complex projects requiring full team collaboration, consider the full BMad Method with specialized agents.
 
-## Frequently Asked Questions
+### Is the code review step mandatory?
 
-**Q: When should I use Barry vs other agents?**
-A: Use Barry for Quick Flow development (small to medium features), rapid prototyping, or when you need elite solo development. For large, complex projects requiring full team collaboration, consider the full BMad Method with specialized agents.
+No, it's optional but highly recommended for critical features, team projects, or when learning best practices.
 
-**Q: Is the code review step mandatory?**
-A: No, it's optional but highly recommended for critical features, team projects, or when learning best practices.
+### Can I skip the tech spec step?
 
-**Q: Can I skip the tech spec step?**
-A: Yes, the quick-dev workflow accepts direct instructions. However, tech specs are recommended for complex features or team collaboration.
+Yes, the quick-dev workflow accepts direct instructions. However, tech specs are recommended for complex features or team collaboration.
 
-**Q: How does Barry differ from the Dev agent?**
-A: Barry handles the complete Quick Flow process (spec → dev → review) with elite architectural expertise, while the Dev agent specializes in pure implementation tasks. Barry is your autonomous end-to-end solution.
+### How does Barry differ from the Dev agent?
 
-**Q: Can Barry handle enterprise-scale projects?**
-A: For enterprise-scale projects requiring full team collaboration, consider using the Enterprise Method track. Barry is optimized for rapid delivery in the Quick Flow track where solo execution wins.
+Barry handles the complete Quick Flow process (spec → dev → review) with elite architectural expertise, while the Dev agent specializes in pure implementation tasks. Barry is your autonomous end-to-end solution.
 
----
+### Can Barry handle enterprise-scale projects?
 
-**Ready to ship some code?** → Start with `/bmad:bmm:agents:quick-flow-solo-dev`
+For enterprise-scale projects requiring full team collaboration, consider using the Enterprise Method track. Barry is optimized for rapid delivery in the Quick Flow track where solo execution wins.
+
+:::tip[Ready to Ship?]
+Start with `/bmad:bmm:agents:quick-flow-solo-dev`
+:::

docs/explanation/agents/index.md

@@ -3,26 +3,17 @@ title: "Understanding Agents"
 description: Understanding BMad agents and their roles
 ---
 
-
-Comprehensive guides to BMad's AI agents - their roles, capabilities, and how to work with them effectively.
-
----
+Comprehensive guides to BMad's AI agents — their roles, capabilities, and how to work with them effectively.
 
 ## Agent Guides
 
-### BMM Agents
+| Agent                                                                           | Description                                          |
+| ------------------------------------------------------------------------------- | ---------------------------------------------------- |
+| **[Agent Roles](/docs/explanation/core-concepts/agent-roles.md)**               | Overview of all BMM agent roles and responsibilities |
+| **[Quick Flow Solo Dev (Barry)](/docs/explanation/agents/barry-quick-flow.md)** | The dedicated agent for rapid development            |
 
-- **[Agent Roles](/docs/explanation/core-concepts/agent-roles.md)** - Overview of all BMM agent roles and responsibilities
-- **[Quick Flow Solo Dev (Barry)](/docs/explanation/agents/barry-quick-flow.md)** - The dedicated agent for rapid development
+## Getting Started
 
-### BMGD Agents
-
-- **[Game Development Agents](/docs/explanation/game-dev/agents.md)** - Complete guide to BMGD's specialized game dev agents
-
----
-
-## Related
-
-- **[What Are Agents?](/docs/explanation/core-concepts/what-are-agents.md)** - Core concept explanation
-- **[Party Mode](/docs/explanation/features/party-mode.md)** - Multi-agent collaboration
-- **[Customize Agents](/docs/how-to/customization/customize-agents.md)** - How to customize agent behavior
+1. Read **[What Are Agents?](/docs/explanation/core-concepts/what-are-agents.md)** for the core concept explanation
+2. Review **[Agent Roles](/docs/explanation/core-concepts/agent-roles.md)** to understand available agents
+3. Choose an agent that fits your workflow needs

docs/explanation/architecture/four-phases.md

@@ -6,8 +6,6 @@ description: Understanding the four phases of the BMad Method
 
 BMad Method uses a four-phase approach that adapts to project complexity while ensuring consistent quality.
 
----
-
 ## Phase Overview
 
 | Phase | Name | Purpose | Required? |
@@ -17,8 +15,6 @@ BMad Method uses a four-phase approach that adapts to project complexity while e
 | **Phase 3** | Solutioning | Technical design | Track-dependent |
 | **Phase 4** | Implementation | Building the software | Required |
 
----
-
 ## Phase 1: Analysis (Optional)
 
 Exploration and discovery workflows that help validate ideas and understand markets before planning.
@@ -38,8 +34,6 @@ Exploration and discovery workflows that help validate ideas and understand mark
 - Well-defined features
 - Continuing existing work
 
----
-
 ## Phase 2: Planning (Required)
 
 Requirements definition using the scale-adaptive system to match planning depth to project complexity.
@@ -52,8 +46,6 @@ Requirements definition using the scale-adaptive system to match planning depth
 **Key principle:**
 Define **what** to build and **why**. Leave **how** to Phase 3.
 
----
-
 ## Phase 3: Solutioning (Track-Dependent)
 
 Technical architecture and design decisions that prevent agent conflicts during implementation.
@@ -73,8 +65,6 @@ Technical architecture and design decisions that prevent agent conflicts during
 **Key principle:**
 Make technical decisions explicit so all agents implement consistently.
 
----
-
 ## Phase 4: Implementation (Required)
 
 Iterative sprint-based development with story-centric workflow.
@@ -86,10 +76,9 @@ Iterative sprint-based development with story-centric workflow.
 - `code-review` - Quality assurance
 - `retrospective` - Continuous improvement
 
-**Key principle:**
-One story at a time, complete each story's full lifecycle before starting the next.
-
----
+:::tip[Key Principle]
+One story at a time — complete each story's full lifecycle before starting the next.
+:::
 
 ## Phase Flow by Track
 
@@ -116,11 +105,3 @@ Phase 1 → Phase 2 (PRD) → Phase 3 (architecture + extended) → Phase 4 (imp
 ```
 
 Same as BMad Method with optional extended workflows.
-
----
-
-## Related
-
-- [Why Solutioning Matters](/docs/explanation/architecture/why-solutioning-matters.md)
-- [Preventing Agent Conflicts](/docs/explanation/architecture/preventing-agent-conflicts.md)
-- [Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md)

docs/explanation/architecture/preventing-agent-conflicts.md

@@ -6,8 +6,6 @@ description: How architecture prevents conflicts when multiple agents implement
 
 When multiple AI agents implement different parts of a system, they can make conflicting technical decisions. Architecture documentation prevents this by establishing shared standards.
 
----
-
 ## Common Conflict Types
 
 ### API Style Conflicts
@@ -43,8 +41,6 @@ With architecture:
 - ADR specifies state management approach
 - All agents implement consistently
 
----
-
 ## How Architecture Prevents Conflicts
 
 ### 1. Explicit Decisions via ADRs
@@ -70,8 +66,6 @@ Explicit documentation of:
 - Code organization
 - Testing patterns
 
----
-
 ## Architecture as Shared Context
 
 Think of architecture as the shared context that all agents read before implementing:
@@ -88,8 +82,6 @@ Agent C reads architecture → implements Epic 3
 Result: Consistent implementation
 ```
 
----
-
 ## Key ADR Topics
 
 Common decisions that prevent conflicts:
@@ -103,36 +95,17 @@ Common decisions that prevent conflicts:
 | Styling | CSS Modules vs Tailwind vs Styled Components |
 | Testing | Jest + Playwright vs Vitest + Cypress |
 
----
+## Anti-Patterns to Avoid
 
-## Anti-Patterns
-
-### ❌ Implicit Decisions
-
-"We'll figure out the API style as we go"
-→ Leads to inconsistency
-
-### ❌ Over-Documentation
-
-Every minor choice documented
-→ Analysis paralysis, wasted time
-
-### ❌ Stale Architecture
-
-Document written once, never updated
-→ Agents follow outdated patterns
-
-### ✅ Correct Approach
+:::caution[Common Mistakes]
+- **Implicit Decisions** — "We'll figure out the API style as we go" leads to inconsistency
+- **Over-Documentation** — Documenting every minor choice causes analysis paralysis
+- **Stale Architecture** — Documents written once and never updated cause agents to follow outdated patterns
+:::
 
+:::tip[Correct Approach]
 - Document decisions that cross epic boundaries
 - Focus on conflict-prone areas
 - Update architecture as you learn
 - Use `correct-course` for significant changes
-
----
-
-## Related
-
-- [Why Solutioning Matters](/docs/explanation/architecture/why-solutioning-matters.md)
-- [Four Phases](/docs/explanation/architecture/four-phases.md)
-- [Create Architecture](/docs/how-to/workflows/create-architecture.md)
+:::

docs/explanation/architecture/why-solutioning-matters.md

@@ -6,8 +6,6 @@ description: Understanding why the solutioning phase is critical for multi-epic
 
 Phase 3 (Solutioning) translates **what** to build (from Planning) into **how** to build it (technical design). This phase prevents agent conflicts in multi-epic projects by documenting architectural decisions before implementation begins.
 
----
-
 ## The Problem Without Solutioning
 
 ```
@@ -18,8 +16,6 @@ Result: Inconsistent API design, integration nightmare
 
 When multiple agents implement different parts of a system without shared architectural guidance, they make independent technical decisions that may conflict.
 
----
-
 ## The Solution With Solutioning
 
 ```
@@ -30,8 +26,6 @@ Result: Consistent implementation, no conflicts
 
 By documenting technical decisions explicitly, all agents implement consistently and integration becomes straightforward.
 
----
-
 ## Solutioning vs Planning
 
 | Aspect   | Planning (Phase 2)      | Solutioning (Phase 3)             |
@@ -43,8 +37,6 @@ By documenting technical decisions explicitly, all agents implement consistently
 | Document | PRD (FRs/NFRs)          | Architecture + Epic Files         |
 | Level    | Business logic          | Technical design + Work breakdown |
 
----
-
 ## Key Principle
 
 **Make technical decisions explicit and documented** so all agents implement consistently.
@@ -56,8 +48,6 @@ This prevents:
 - Naming convention mismatches
 - Security approach variations
 
----
-
 ## When Solutioning is Required
 
 | Track | Solutioning Required? |
@@ -67,9 +57,9 @@ This prevents:
 | BMad Method Complex | Yes |
 | Enterprise | Yes |
 
-**Rule of thumb:** If you have multiple epics that could be implemented by different agents, you need solutioning.
-
----
+:::tip[Rule of Thumb]
+If you have multiple epics that could be implemented by different agents, you need solutioning.
+:::
 
 ## The Cost of Skipping
 
@@ -80,12 +70,6 @@ Skipping solutioning on complex projects leads to:
 - **Longer development time** overall
 - **Technical debt** from inconsistent patterns
 
+:::caution[Cost Multiplier]
 Catching alignment issues in solutioning is 10× faster than discovering them during implementation.
-
----
-
-## Related
-
-- [Four Phases](/docs/explanation/architecture/four-phases.md) - Overview of all phases
-- [Preventing Agent Conflicts](/docs/explanation/architecture/preventing-agent-conflicts.md) - Detailed conflict prevention
-- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - How to do it
+:::

docs/explanation/bmad-builder/custom-content-types.md

@@ -2,10 +2,13 @@
 title: "Custom Content"
 ---
 
+BMad supports several categories of custom content that extend the platform's capabilities — from simple personal agents to full-featured professional modules.
 
-BMad supports several categories of officially supported custom content that extend the platform's capabilities. Custom content can be created manually or with the recommended assistance of the BMad Builder (BoMB) Module. The BoMB Agents provides workflows and expertise to plan and build any custom content you can imagine.
+:::tip[Recommended Approach]
+Use the BMad Builder (BoMB) Module for guided workflows and expertise when creating custom content.
+:::
 
-This flexibility transforms the platform beyond its current capabilities, enabling:
+This flexibility enables:
 
 - Extensions and add-ons for existing modules (BMad Method, Creative Intelligence Suite)
 - Completely new modules, workflows, templates, and agents outside software engineering
@@ -17,10 +20,13 @@ This flexibility transforms the platform beyond its current capabilities, enabli
 
 ## Categories
 
+- [Categories](#categories)
 - [Custom Stand-Alone Modules](#custom-stand-alone-modules)
 - [Custom Add-On Modules](#custom-add-on-modules)
 - [Custom Global Modules](#custom-global-modules)
 - [Custom Agents](#custom-agents)
+  - [BMad Tiny Agents](#bmad-tiny-agents)
+  - [Simple and Expert Agents](#simple-and-expert-agents)
 - [Custom Workflows](#custom-workflows)
 
 ## Custom Stand-Alone Modules
@@ -56,7 +62,6 @@ Similar to Custom Stand-Alone Modules, but designed to add functionality that ap
 
 Examples include:
 
-- The current TTS (Text-to-Speech) functionality for Claude, which will soon be converted to a global module
 - The core module, which is always installed and provides all agents with party mode and advanced elicitation capabilities
 - Installation and update tools that work with any BMad method configuration
 
@@ -96,7 +101,9 @@ The distinction between simple and expert agents lies in their structure:
 - When installed, the sidecar folder (`[agentname]-sidecar`) is placed in the user memory location
 - has metadata type: expert
 
+:::note[Key Distinction]
 The key distinction is the presence of a sidecar folder. As web and consumer agent tools evolve to support common memory mechanisms, storage formats, and MCP, the writable memory files will adapt to support these evolving standards.
+:::
 
 Custom agents can be:
 
@@ -117,4 +124,6 @@ A custom workflow created outside of a larger module can still be distributed an
 - Slash commands
 - Manual command/prompt execution when supported by tools
 
+:::tip[Core Concept]
 At its core, a custom workflow is a single or series of prompts designed to achieve a specific outcome.
+:::

docs/explanation/bmad-builder/index.md

@@ -3,64 +3,43 @@ title: "BMad Builder (BMB)"
 description: Create custom agents, workflows, and modules for BMad
 ---
 
-
-Create custom agents, workflows, and modules for BMad.
-
----
+Create custom agents, workflows, and modules for BMad — from simple personal assistants to full-featured professional tools.
 
 ## Quick Start
 
-- **[Agent Creation Guide](/docs/tutorials/advanced/create-custom-agent.md)** - Step-by-step guide to building your first agent
-
----
+| Resource | Description |
+|----------|-------------|
+| **[Agent Creation Guide](/docs/tutorials/advanced/create-custom-agent.md)** | Step-by-step guide to building your first agent |
+| **[Install Custom Modules](/docs/how-to/installation/install-custom-modules.md)** | Installing standalone simple and expert agents |
 
 ## Agent Architecture
 
-Comprehensive guides for each agent type:
-
-- **Simple Agent Architecture** - Self-contained, optimized, personality-driven
-- **Expert Agent Architecture** - Memory, sidecar files, domain restrictions
-- **Module Agent Architecture** - Workflow integration, professional tools
-
----
+| Type | Description |
+|------|-------------|
+| **Simple Agent** | Self-contained, optimized, personality-driven |
+| **Expert Agent** | Memory, sidecar files, domain restrictions |
+| **Module Agent** | Workflow integration, professional tools |
 
 ## Key Concepts
 
-### YAML to XML Compilation
-
 Agents are authored in YAML with Handlebars templating. The compiler auto-injects:
 
-1. **Frontmatter** - Name and description from metadata
-2. **Activation Block** - Steps, menu handlers, rules
-3. **Menu Enhancement** - `*help` and `*exit` commands added automatically
-4. **Trigger Prefixing** - Your triggers auto-prefixed with `*`
+1. **Frontmatter** — Name and description from metadata
+2. **Activation Block** — Steps, menu handlers, rules
+3. **Menu Enhancement** — `*help` and `*exit` commands added automatically
+4. **Trigger Prefixing** — Your triggers auto-prefixed with `*`
 
----
+:::note[Learn More]
+See [Custom Content Types](/docs/explanation/bmad-builder/custom-content-types.md) for detailed explanations of all content categories.
+:::
 
 ## Reference Examples
 
 Production-ready examples available in the BMB reference folder:
 
-### Simple Agents
-- **commit-poet** - Commit message artisan with style customization
-
-### Expert Agents
-- **journal-keeper** - Personal journal companion with memory and pattern recognition
-
-### Module Agents
-- **security-engineer** - BMM security specialist with threat modeling
-- **trend-analyst** - CIS trend intelligence expert
-
----
-
-## Installation Guide
-
-For installing standalone simple and expert agents, see:
-- [Install Custom Modules](/docs/how-to/installation/install-custom-modules.md)
-
----
-
-## Related
-
-- [Custom Content Types](/docs/explanation/bmad-builder/custom-content-types.md) - Understanding content types
-- [Create Custom Agent](/docs/tutorials/advanced/create-custom-agent.md) - Tutorial
+| Agent | Type | Description |
+|-------|------|-------------|
+| **commit-poet** | Simple | Commit message artisan with style customization |
+| **journal-keeper** | Expert | Personal journal companion with memory and pattern recognition |
+| **security-engineer** | Module | BMM security specialist with threat modeling |
+| **trend-analyst** | Module | CIS trend intelligence expert |

docs/explanation/bmm/index.md

@@ -2,28 +2,22 @@
 title: "BMM Documentation"
 ---
 
+Complete guides for the BMad Method Module (BMM) — AI-powered agile development workflows that adapt to your project's complexity.
 
-Complete guides for the BMad Method Module (BMM) - AI-powered agile development workflows that adapt to your project's complexity.
+## Getting Started
 
----
-
-## 🚀 Getting Started
+:::tip[Quick Path]
+Install → workflow-init → Follow agent guidance
+:::
 
 **New to BMM?** Start here:
 
-- **[Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md)** - Step-by-step guide to building your first project
-  - Installation and setup
-  - Understanding the four phases
-  - Running your first workflows
-  - Agent-based development flow
+| Resource | Description |
+|----------|-------------|
+| **[Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md)** | Step-by-step guide to building your first project |
+| **[Complete Workflow Diagram](../../tutorials/getting-started/images/workflow-method-greenfield.svg)** | Visual flowchart showing all phases, agents, and decision points |
 
-**Quick Path:** Install → workflow-init → Follow agent guidance
-
-### 📊 Visual Overview
-
-**[Complete Workflow Diagram](../../tutorials/getting-started/images/workflow-method-greenfield.svg)** - Visual flowchart showing all phases, agents (color-coded), and decision points for the BMad Method standard greenfield track.
-
-## 📖 Core Concepts
+## Core Concepts
 
 The BMad Method is meant to be adapted and customized to your specific needs. In this realm there is no one size fits all - your needs are unique, and BMad Method is meant to support this (and if it does not, can be further customized or extended with new modules).
 
@@ -45,7 +39,7 @@ First know there is the full BMad Method Process and then there is a Quick Flow
 
 - **TEA engagement (optional)** - Choose TEA engagement: none, TEA-only (standalone), or integrated by track. See **[Test Architect Guide](/docs/explanation/features/tea-overview.md)**.
 
-## 🤖 Agents and Collaboration
+## Agents and Collaboration
 
 Complete guide to BMM's AI agent team:
 
@@ -63,7 +57,7 @@ Complete guide to BMM's AI agent team:
   - Agent customization in party mode
   - Best practices
 
-## 🔧 Working with Existing Code
+## Working with Existing Code
 
 Comprehensive guide for brownfield development:
 
@@ -74,14 +68,14 @@ Comprehensive guide for brownfield development:
   - Phase-by-phase workflow guidance
   - Common scenarios
 
-## 📚 Quick References
+## Quick References
 
 Essential reference materials:
 
 - **[Glossary](/docs/reference/glossary/index.md)** - Key terminology and concepts
 - **[FAQ](/docs/explanation/faq/index.md)** - Frequently asked questions across all topics
 
-## 🎯 Choose Your Path
+## Choose Your Path
 
 ### I need to...
 
@@ -95,7 +89,7 @@ Essential reference materials:
 → Read [Brownfield Development Guide](/docs/how-to/brownfield/index.md)
 → Pay special attention to documentation requirements for brownfield projects
 
-## 📋 Workflow Guides
+## Workflow Guides
 
 Comprehensive documentation for all BMM workflows organized by phase:
 
@@ -124,7 +118,7 @@ Comprehensive documentation for all BMM workflows organized by phase:
   - Test strategy, automation, quality gates
   - TEA agent and test healing
 
-## 🌐 External Resources
+## External Resources
 
 ### Community and Support
 
@@ -132,4 +126,6 @@ Comprehensive documentation for all BMM workflows organized by phase:
 - **[GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)** - Report bugs or request features
 - **[YouTube Channel](https://www.youtube.com/@BMadCode)** - Video tutorials and walkthroughs
 
-**Ready to begin?** → [Start with the Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md)
+:::tip[Ready to Begin?]
+[Start with the Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md)
+:::

docs/explanation/core-concepts/agent-roles.md

@@ -3,11 +3,8 @@ title: "Agent Roles in BMad Method"
 description: Understanding the different agent roles in BMad Method
 ---
 
-
 BMad Method uses specialized AI agents, each with a distinct role, expertise, and personality. Understanding these roles helps you know which agent to use for each task.
 
----
-
 ## Core Agents Overview
 
 | Agent | Role | Primary Phase |
@@ -21,8 +18,6 @@ BMad Method uses specialized AI agents, each with a distinct role, expertise, an
 | **UX Designer** | User experience | Phase 2-3 |
 | **Quick Flow Solo Dev** | Fast solo development | All phases (Quick Flow) |
 
----
-
 ## Phase 1: Analysis
 
 ### Analyst (Mary)
@@ -43,8 +38,6 @@ Business analysis and research specialist.
 
 **When to use:** Starting new projects, exploring ideas, validating market fit, documenting existing codebases.
 
----
-
 ## Phase 2: Planning
 
 ### PM (John)
@@ -80,8 +73,6 @@ User experience and UI design specialist.
 
 **When to use:** When UX is a primary differentiator, complex user workflows, design system creation.
 
----
-
 ## Phase 3: Solutioning
 
 ### Architect (Winston)
@@ -100,8 +91,6 @@ System architecture and technical design expert.
 
 **When to use:** Multi-epic projects, cross-cutting technical decisions, preventing agent conflicts.
 
----
-
 ## Phase 4: Implementation
 
 ### SM (Bob)
@@ -138,8 +127,6 @@ Story implementation and code review specialist.
 
 **When to use:** Writing code, implementing stories, reviewing quality.
 
----
-
 ## Cross-Phase Agents
 
 ### TEA (Murat)
@@ -159,8 +146,6 @@ Test architecture and quality strategy expert.
 
 **When to use:** Setting up testing, creating test plans, quality gates.
 
----
-
 ## Quick Flow
 
 ### Quick Flow Solo Dev (Barry)
@@ -179,8 +164,6 @@ Fast solo development without handoffs.
 
 **When to use:** Bug fixes, small features, rapid prototyping.
 
----
-
 ## Choosing the Right Agent
 
 | Task | Agent |
@@ -194,11 +177,3 @@ Fast solo development without handoffs.
 | Writing code | DEV |
 | Setting up tests | TEA |
 | Quick bug fix | Quick Flow Solo Dev |
-
----
-
-## Related
-
-- [What Are Agents](/docs/explanation/core-concepts/what-are-agents.md) - Foundational concepts
-- [Agent Reference](/docs/reference/agents/index.md) - Complete command reference
-- [Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md)

docs/explanation/core-concepts/index.md

@@ -2,7 +2,6 @@
 title: "BMad Core Concepts"
 ---
 
-
 Understanding the fundamental building blocks of the BMad Method.
 
 ## The Essentials
@@ -34,7 +33,3 @@ Start here to understand what BMad is and how it works:
 ### Advanced
 
 - **[Web Bundles](/docs/explanation/features/web-bundles.md)** - Use BMad in Gemini Gems and Custom GPTs
-
----
-
-**Next:** Read the [Agents Guide](/docs/explanation/core-concepts/what-are-agents.md) to understand the core building block of BMad.

docs/explanation/core-concepts/what-are-agents.md

@@ -2,7 +2,6 @@
 title: "Agents"
 ---
 
-
 Agents are AI assistants that help you accomplish tasks. Each agent has a unique personality, specialized capabilities, and an interactive menu.
 
 ## Agent Types
@@ -72,6 +71,10 @@ All agents share these building blocks:
 
 ## Which Should You Use?
 
+:::tip[Quick Decision]
+Choose **Simple** for focused, one-off tasks with no memory needs. Choose **Expert** when you need persistent context and complex workflows.
+:::
+
 **Choose Simple when:**
 - You need a task done quickly and reliably
 - The scope is well-defined and won't change much
@@ -90,7 +93,3 @@ BMad provides the **BMad Builder (BMB)** module for creating your own agents. Se
 ## Customizing Existing Agents
 
 You can modify any agent's behavior without editing core files. See [BMad Customization](/docs/how-to/customization/index.md) for details. It is critical to never modify an installed agents .md file directly and follow the customization process, this way future updates to the agent or module its part of will continue to be updated and recompiled with the installer tool, and your customizations will still be retained.
-
----
-
-**Next:** Learn about [Workflows](/docs/explanation/core-concepts/what-are-workflows.md) to see how agents accomplish complex tasks.

docs/explanation/core-concepts/what-are-modules.md

@@ -2,7 +2,6 @@
 title: "Modules"
 ---
 
-
 Modules are organized collections of agents and workflows that solve specific problems or address particular domains.
 
 ## What is a Module?
@@ -14,7 +13,11 @@ A module is a self-contained package that includes:
 - **Configuration** - Module-specific settings
 - **Documentation** - Usage guides and reference
 
-## Official Modules
+## Official BMad Method and Builder Modules
+
+:::note[Core is Always Installed]
+The Core module is automatically included with every BMad installation. It provides the foundation that other modules build upon.
+:::
 
 ### Core Module
 Always installed, provides shared functionality:
@@ -34,17 +37,24 @@ Create custom solutions:
 - Workflow authoring tools
 - Module scaffolding
 
+## Additional Official BMad Modules
+
+These are officially maintained modules by BMad but have their own repo's and docs.
+These give a good idea also of what can be done with the BMad builder and creating your own custom modules.
+
 ### Creative Intelligence Suite (CIS)
 Innovation and creativity:
 - Creative thinking techniques
 - Innovation strategy workflows
 - Storytelling and ideation
+- [Available Here](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)
 
 ### BMad Game Dev (BMGD)
 Game development specialization:
 - Game design workflows
 - Narrative development
 - Performance testing frameworks
+- [Available Here](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
 
 ## Module Structure
 
@@ -73,7 +83,3 @@ Custom modules are installed the same way as official modules.
 During BMad installation, you choose which modules to install. You can also add or remove modules later by re-running the installer.
 
 See [Installation Guide](/docs/how-to/installation/index.md) for details.
-
----
-
-**Next:** Read the [Installation Guide](/docs/how-to/installation/index.md) to set up BMad with the modules you need.

docs/explanation/core-concepts/what-are-workflows.md

@@ -2,13 +2,10 @@
 title: "Workflows"
 ---
 
-
 Workflows are like prompts on steroids. They harness the untapped power and control of LLMs through progressive disclosure—breaking complex tasks into focused steps that execute sequentially. Instead of random AI slop where you hope for the best, workflows give you repeatable, reliable, high-quality outputs.
 
 This guide explains what workflows are, why they're powerful, and how to think about designing them.
 
----
-
 ## What Is a Workflow?
 
 A workflow is a structured process where the AI executes steps sequentially to accomplish a task. Each step has a specific purpose, and the AI moves through them methodically—whether that involves extensive collaboration or minimal user interaction.
@@ -71,9 +68,9 @@ When workflows involve users, they should be **facilitative, not directive**. Th
 
 The AI figures out exact wording and question order based on conversation context. This makes interactions feel natural and responsive rather than robotic and interrogative.
 
-**When to be prescriptive**: Some workflows require exact scripts—medical intake, legal compliance, safety-critical procedures. But these are the exception, not the rule. Default to facilitative intent-based approaches unless compliance or regulation demands otherwise.
-
----
+:::caution[When to Be Prescriptive]
+Some workflows require exact scripts—medical intake, legal compliance, safety-critical procedures. But these are the exception. Default to facilitative intent-based approaches unless compliance or regulation demands otherwise.
+:::
 
 ## Why Workflows Matter
 
@@ -85,8 +82,6 @@ Workflows solve three fundamental problems with AI interactions:
 
 **Quality**: Sequential enforcement prevents shortcuts. The AI must complete each step fully before moving on, ensuring thorough, complete outputs instead of rushed, half-baked results.
 
----
-
 ## How Workflows Work
 
 ### The Basic Structure
@@ -150,8 +145,6 @@ All BMad planning workflows and the BMB module (will) use this tri-modal pattern
 
 This tri-modal approach gives you the best of both worlds: the creativity and flexibility to build what you need, the quality assurance of validation that can run anytime, and the ability to iterate while staying true to standards that make the artifacts valuable across sessions and team members.
 
----
-
 ## Design Decisions
 
 Before building a workflow, answer these questions:
@@ -166,13 +159,11 @@ Before building a workflow, answer these questions:
 
 **Intent or prescriptive?**: Is this intent-based facilitation (most workflows) or prescriptive compliance (medical, legal, regulated)?
 
----
-
 ## Learning from Examples
 
 The best way to understand workflows is to study real examples. Look at the official BMad modules:
 
-- **BMB (Module Builder)**: Workflow and agent creation workflows
+- **BMB (Module Builder)**: Module, Workflow and Agent creation workflows
 - **BMM (Business Method Module)**: Complete software development pipeline from brainstorming through sprint planning
 - **BMGD (Game Development Module)**: Game design briefs, narratives, architecture
 - **CIS (Creativity, Innovation, Strategy)**: Brainstorming, design thinking, storytelling, innovation strategy
@@ -181,8 +172,6 @@ Study the workflow.md files to understand how each workflow starts. Examine step
 
 Copy patterns that work. Adapt them to your domain. The structure is consistent across all workflows—the content and steps change, but the architecture stays the same.
 
----
-
 ## When to Use Workflows
 
 Use workflows when:
@@ -206,8 +195,6 @@ Modified BMad Workflows
 If there's only one thing to do and it can be explained in under about 300 lines - don't bother with step files. Instead, you can still have
 a short single file workflow.md file.
 
----
-
 ## The Bottom Line
 
 Workflows transform AI from a tool that gives variable, unpredictable results into a reliable system for complex, multi-step processes. Through progressive disclosure, sequential execution, guided facilitation, and thoughtful design, workflows give you control and repeatability that ad-hoc prompting alone can't match.

docs/explanation/core/index.md

@@ -14,5 +14,5 @@ The Core Module is installed with all installations of BMad modules and provides
   - [Advanced Elicitation](/docs/explanation/features/advanced-elicitation.md) — LLM rethinking with 50+ reasoning methods
 - **[Core Tasks](/docs/reference/configuration/core-tasks.md)** — Common tasks available across modules
   - [Index Docs](/docs/reference/configuration/core-tasks.md#index-docs) — Generate directory index files
-  - [Adversarial Review](/docs/reference/configuration/core-tasks.md#adversarial-review-general) — Critical content review
+  - [Adversarial Review](/docs/reference/configuration/core-tasks.md#adversarial-review) — Critical content review
   - [Shard Document](/docs/reference/configuration/core-tasks.md#shard-document) — Split large documents into sections

docs/explanation/creative-intelligence/index.md

@@ -1,121 +0,0 @@
----
-title: "Creative Intelligence Suite (CIS)"
-description: AI-powered creative facilitation with the Creative Intelligence Suite
----
-
-
-AI-powered creative facilitation transforming strategic thinking through expert coaching across five specialized domains.
-
----
-
-## Core Capabilities
-
-CIS provides structured creative methodologies through distinctive agent personas who act as master facilitators, drawing out insights through strategic questioning rather than generating solutions directly.
-
----
-
-## Specialized Agents
-
-- **Carson** - Brainstorming Specialist (energetic facilitator)
-- **Maya** - Design Thinking Maestro (jazz-like improviser)
-- **Dr. Quinn** - Problem Solver (detective-scientist hybrid)
-- **Victor** - Innovation Oracle (bold strategic precision)
-- **Sophia** - Master Storyteller (whimsical narrator)
-
----
-
-## Interactive Workflows
-
-**5 Workflows** with **150+ Creative Techniques:**
-
-### Brainstorming
-
-36 techniques across 7 categories for ideation:
-- Divergent/convergent thinking
-- Lateral connections
-- Forced associations
-
-### Design Thinking
-
-Complete 5-phase human-centered process:
-- Empathize → Define → Ideate → Prototype → Test
-- User journey mapping
-- Rapid iteration
-
-### Problem Solving
-
-Systematic root cause analysis:
-- 5 Whys, Fishbone diagrams
-- Solution generation
-- Impact assessment
-
-### Innovation Strategy
-
-Business model disruption:
-- Blue Ocean Strategy
-- Jobs-to-be-Done
-- Disruptive innovation patterns
-
-### Storytelling
-
-25 narrative frameworks:
-- Hero's Journey
-- Story circles
-- Compelling pitch structures
-
----
-
-## Quick Start
-
-### Direct Workflow
-
-```bash
-workflow brainstorming
-
-workflow design-thinking --data /path/to/context.md
-```
-
-### Agent-Facilitated
-
-```bash
-agent cis/brainstorming-coach
-
-> *brainstorm
-```
-
----
-
-## Key Differentiators
-
-- **Facilitation Over Generation** - Guides discovery through questions
-- **Energy-Aware Sessions** - Adapts to engagement levels
-- **Context Integration** - Domain-specific guidance support
-- **Persona-Driven** - Unique communication styles
-- **Rich Method Libraries** - 150+ proven techniques
-
----
-
-## Integration Points
-
-CIS workflows integrate with:
-
-- **BMM** - Powers project brainstorming
-- **BMB** - Creative module design
-- **Custom Modules** - Shared creative resource
-
----
-
-## Best Practices
-
-1. **Set clear objectives** before starting sessions
-2. **Provide context documents** for domain relevance
-3. **Trust the process** - Let facilitation guide you
-4. **Take breaks** when energy flags
-5. **Document insights** as they emerge
-
----
-
-## Related
-
-- [Facilitation Over Generation](/docs/explanation/philosophy/facilitation-over-generation.md) - Core philosophy
-- [Brainstorming Techniques](/docs/explanation/features/brainstorming-techniques.md) - Technique reference

docs/explanation/faq/getting-started-faq.md

@@ -7,12 +7,17 @@ Quick answers to common questions about getting started with the BMad Method.
 
 ## Questions
 
+- [Why does BMad use so many tokens?](#why-does-bmad-use-so-many-tokens)
 - [Do I always need to run workflow-init?](#do-i-always-need-to-run-workflow-init)
 - [Why do I need fresh chats for each workflow?](#why-do-i-need-fresh-chats-for-each-workflow)
 - [Can I skip workflow-status and just start working?](#can-i-skip-workflow-status-and-just-start-working)
 - [What's the minimum I need to get started?](#whats-the-minimum-i-need-to-get-started)
 - [How do I know if I'm in Phase 1, 2, 3, or 4?](#how-do-i-know-if-im-in-phase-1-2-3-or-4)
 
+### Why does BMad use so many tokens?
+
+BMad is not always the most token efficient approach, and that's by design. The checkpoints, story files, and retrospectives keep you in the loop so you can apply taste, judgment, and accumulated context that no agent has. Fully automated coding loops optimize for code velocity; BMad optimizes for decision quality. If you're building something you'll maintain for years, where user experience matters, where architectural choices compound—that tradeoff pays for itself.
+
 ### Do I always need to run workflow-init?
 
 No, once you learn the flow you can go directly to workflows. However, workflow-init is helpful because it:

docs/explanation/faq/tools-faq.md

@@ -9,21 +9,45 @@ Quick answers to common questions about tools, IDEs, and advanced topics in the
 
 **Tools and Technical**
 
-- [Why are my Mermaid diagrams not rendering?](#why-are-my-mermaid-diagrams-not-rendering)
-- [Can I use BMM with GitHub Copilot / Cursor / other AI tools?](#can-i-use-bmm-with-github-copilot--cursor--other-ai-tools)
-- [What IDEs/tools support BMM?](#what-idestools-support-bmm)
-- [Can I customize agents?](#can-i-customize-agents)
-- [What happens to my planning docs after implementation?](#what-happens-to-my-planning-docs-after-implementation)
-- [Can I use BMM for non-software projects?](#can-i-use-bmm-for-non-software-projects)
+- [Questions](#questions)
+- [Tools and Technical](#tools-and-technical)
+  - [Why are my Mermaid diagrams not rendering?](#why-are-my-mermaid-diagrams-not-rendering)
+  - [Can I use BMM with GitHub Copilot / Cursor / other AI tools?](#can-i-use-bmm-with-github-copilot--cursor--other-ai-tools)
+  - [What IDEs/tools support BMM?](#what-idestools-support-bmm)
+  - [Can I customize agents?](#can-i-customize-agents)
+  - [What happens to my planning docs after implementation?](#what-happens-to-my-planning-docs-after-implementation)
+  - [Can I use BMM for non-software projects?](#can-i-use-bmm-for-non-software-projects)
+- [Advanced](#advanced)
+  - [What if my project grows from Level 1 to Level 3?](#what-if-my-project-grows-from-level-1-to-level-3)
+  - [Can I mix greenfield and brownfield approaches?](#can-i-mix-greenfield-and-brownfield-approaches)
+  - [How do I handle urgent hotfixes during a sprint?](#how-do-i-handle-urgent-hotfixes-during-a-sprint)
+  - [What if I disagree with the workflow's recommendations?](#what-if-i-disagree-with-the-workflows-recommendations)
+  - [Can multiple developers work on the same BMM project?](#can-multiple-developers-work-on-the-same-bmm-project)
+  - [What is party mode and when should I use it?](#what-is-party-mode-and-when-should-i-use-it)
+- [Getting Help](#getting-help)
+  - [Where do I get help if my question isn't answered here?](#where-do-i-get-help-if-my-question-isnt-answered-here)
+  - [How do I report a bug or request a feature?](#how-do-i-report-a-bug-or-request-a-feature)
 
 **Advanced**
 
-- [What if my project grows from Level 1 to Level 3?](#what-if-my-project-grows-from-level-1-to-level-3)
-- [Can I mix greenfield and brownfield approaches?](#can-i-mix-greenfield-and-brownfield-approaches)
-- [How do I handle urgent hotfixes during a sprint?](#how-do-i-handle-urgent-hotfixes-during-a-sprint)
-- [What if I disagree with the workflow's recommendations?](#what-if-i-disagree-with-the-workflows-recommendations)
-- [Can multiple developers work on the same BMM project?](#can-multiple-developers-work-on-the-same-bmm-project)
-- [What is party mode and when should I use it?](#what-is-party-mode-and-when-should-i-use-it)
+- [Questions](#questions)
+- [Tools and Technical](#tools-and-technical)
+  - [Why are my Mermaid diagrams not rendering?](#why-are-my-mermaid-diagrams-not-rendering)
+  - [Can I use BMM with GitHub Copilot / Cursor / other AI tools?](#can-i-use-bmm-with-github-copilot--cursor--other-ai-tools)
+  - [What IDEs/tools support BMM?](#what-idestools-support-bmm)
+  - [Can I customize agents?](#can-i-customize-agents)
+  - [What happens to my planning docs after implementation?](#what-happens-to-my-planning-docs-after-implementation)
+  - [Can I use BMM for non-software projects?](#can-i-use-bmm-for-non-software-projects)
+- [Advanced](#advanced)
+  - [What if my project grows from Level 1 to Level 3?](#what-if-my-project-grows-from-level-1-to-level-3)
+  - [Can I mix greenfield and brownfield approaches?](#can-i-mix-greenfield-and-brownfield-approaches)
+  - [How do I handle urgent hotfixes during a sprint?](#how-do-i-handle-urgent-hotfixes-during-a-sprint)
+  - [What if I disagree with the workflow's recommendations?](#what-if-i-disagree-with-the-workflows-recommendations)
+  - [Can multiple developers work on the same BMM project?](#can-multiple-developers-work-on-the-same-bmm-project)
+  - [What is party mode and when should I use it?](#what-is-party-mode-and-when-should-i-use-it)
+- [Getting Help](#getting-help)
+  - [Where do I get help if my question isn't answered here?](#where-do-i-get-help-if-my-question-isnt-answered-here)
+  - [How do I report a bug or request a feature?](#how-do-i-report-a-bug-or-request-a-feature)
 
 **Getting Help**
 
@@ -199,11 +223,11 @@ Yes! But the paradigm is fundamentally different from traditional agile teams.
 
 ### What is party mode and when should I use it?
 
-Party mode is a unique multi-agent collaboration feature where ALL your installed agents (19+ from BMM, CIS, BMB, custom modules) discuss your challenges together in real-time.
+Party mode is a unique multi-agent collaboration feature where ALL your installed modules agents discuss your challenges together in real-time or have some fun with any topic you have in mind.
 
 **How it works:**
 
-1. Run `/bmad:core:workflows:party-mode` (or `*party-mode` from any agent)
+1. Run `/bmad:core:workflows:party-mode` (or `PM or fuzzy match on party-mode` from any agent)
 2. Introduce your topic
 3. BMad Master selects 2-3 most relevant agents per message
 4. Agents cross-talk, debate, and build on each other's ideas

docs/explanation/features/advanced-elicitation.md

@@ -2,13 +2,10 @@
 title: "Advanced Elicitation"
 ---
 
-
-**Push the LLM to rethink its work through 50+ reasoning methods—essentially, LLM brainstorming.**
+Push the LLM to rethink its work through 50+ reasoning methods — essentially, LLM brainstorming.
 
 Advanced Elicitation is the inverse of Brainstorming. Instead of pulling ideas out of you, the LLM applies sophisticated reasoning techniques to re-examine and enhance content it has just generated. It's the LLM brainstorming with itself to find better approaches, uncover hidden issues, and discover improvements it missed on the first pass.
 
----
-
 ## When to Use It
 
 - After a workflow generates a section of content and you want to explore alternatives
@@ -17,8 +14,6 @@ Advanced Elicitation is the inverse of Brainstorming. Instead of pulling ideas o
 - To stress-test assumptions, explore edge cases, or find weaknesses in generated plans
 - When you want the LLM to "think again" but with structured reasoning methods
 
----
-
 ## How It Works
 
 ### 1. Context Analysis
@@ -44,8 +39,6 @@ Based on context, 5 methods are intelligently selected from a library of 50+ tec
 ### 4. Party Mode Integration (Optional)
 If Party Mode is active, BMad agents participate randomly in the elicitation process, adding their unique perspectives to the methods.
 
----
-
 ## Method Categories
 
 | Category          | Focus                               | Example Methods                                                |
@@ -62,8 +55,6 @@ If Party Mode is active, BMad agents participate randomly in the elicitation pro
 | **Philosophical** | Conceptual clarity                  | Occam's Razor, Ethical Dilemmas                                |
 | **Retrospective** | Reflection and lessons              | Hindsight Reflection, Lessons Learned Extraction               |
 
----
-
 ## Key Features
 
 - **50+ reasoning methods** — Spanning core logic to advanced multi-step reasoning frameworks
@@ -72,8 +63,6 @@ If Party Mode is active, BMad agents participate randomly in the elicitation pro
 - **User control** — Accept or discard each enhancement before proceeding
 - **Party Mode integration** — Agents can participate when Party Mode is active
 
----
-
 ## Workflow Integration
 
 Advanced Elicitation is a core workflow designed to be invoked by other workflows during content generation:
@@ -96,8 +85,6 @@ When called from a workflow:
 
 A specification generation workflow could invoke Advanced Elicitation after producing each major section (requirements, architecture, implementation plan). The workflow would pass the generated section, and Advanced Elicitation would offer methods like "Stakeholder Round Table" to gather diverse perspectives on requirements, or "Red Team vs Blue Team" to stress-test the architecture for vulnerabilities.
 
----
-
 ## Advanced Elicitation vs. Brainstorming
 
 |              | **Advanced Elicitation**                          | **Brainstorming**                             |

docs/explanation/features/brainstorming-techniques.md

@@ -2,14 +2,13 @@
 title: "Brainstorming"
 ---
 
+Facilitate structured creative sessions using 60+ proven ideation techniques.
 
-**Facilitate structured creative sessions using 60+ proven ideation techniques.**
+The Brainstorming workflow is an interactive facilitation system that helps you unlock your own creativity. The AI acts as coach, guide, and creative partner — using proven techniques to draw out ideas and insights that are already within you.
 
-The Brainstorming workflow is an interactive facilitation system that helps you unlock your own creativity. The AI acts as coach, guide, and creative partner—using proven techniques to draw out ideas and insights that are already within you.
-
-**Important:** Every idea comes from you. The workflow creates the conditions for your best thinking to emerge through guided exploration, but you are the source.
-
----
+:::note[Important]
+Every idea comes from you. The workflow creates the conditions for your best thinking to emerge through guided exploration, but you are the source.
+:::
 
 ## When to Use It
 
@@ -19,8 +18,6 @@ The Brainstorming workflow is an interactive facilitation system that helps you
 - Systematically developing ideas from raw concepts to actionable plans
 - Team ideation (with collaborative techniques) or personal creative exploration
 
----
-
 ## How It Works
 
 ### 1. Session Setup
@@ -44,8 +41,6 @@ All your generated ideas are organized into themes and prioritized.
 ### 5. Action Planning
 Top ideas get concrete next steps, resource requirements, and success metrics.
 
----
-
 ## What You Get
 
 A comprehensive session document that captures the entire journey:
@@ -57,9 +52,7 @@ A comprehensive session document that captures the entire journey:
 - Prioritized ideas with action plans
 - Session highlights and key breakthroughs
 
-This document becomes a permanent record of your creative process—valuable for future reference, sharing with stakeholders, or continuing the session later.
-
----
+This document becomes a permanent record of your creative process — valuable for future reference, sharing with stakeholders, or continuing the session later.
 
 ## Technique Categories
 
@@ -76,8 +69,6 @@ This document becomes a permanent record of your creative process—valuable for
 | **Cultural** | Traditional knowledge and cross-cultural approaches |
 | **Introspective Delight** | Inner wisdom and authentic exploration |
 
----
-
 ## Key Features
 
 - **Interactive coaching** — Pulls ideas *out* of you, doesn't generate them for you
@@ -85,8 +76,6 @@ This document becomes a permanent record of your creative process—valuable for
 - **Session preservation** — Every step, insight, and action plan is documented
 - **Continuation support** — Pause sessions and return later, or extend with additional techniques
 
----
-
 ## Workflow Integration
 
 Brainstorming is a core workflow designed to be invoked and configured by other modules. When called from another workflow, it accepts contextual parameters:

docs/explanation/features/party-mode.md

@@ -2,8 +2,7 @@
 title: "Party Mode: Multi-Agent Collaboration"
 ---
 
-
-**Get all your AI agents in one conversation**
+Get all your AI agents in one conversation.
 
 ## What is Party Mode?
 
@@ -20,8 +19,6 @@ Type `/bmad:core:workflows:party-mode` (or `*party-mode` from any agent or at ke
 - **Sprint retrospectives** - Party mode powers the retrospective workflow
 - **Sprint planning** - Multi-agent collaboration for planning sessions
 
----
-
 ## How It Works
 
 **The basics:**
@@ -34,8 +31,6 @@ Type `/bmad:core:workflows:party-mode` (or `*party-mode` from any agent or at ke
 
 **That's it.** No complex merging, no runtime magic. Just agents talking.
 
----
-
 ## Quick Start
 
 ```bash
@@ -51,8 +46,6 @@ Ask questions, respond to agents, direct the conversation
 Type: exit
 ```
 
----
-
 ## Fun Examples
 
 ### Example 1: Calling Out Bad Architecture
@@ -69,8 +62,6 @@ Type: exit
 
 _(Watch them debate whose fault it really was - it's therapeutic)_
 
----
-
 ### Example 2: Creative Brainstorming
 
 **You:** "How do we make onboarding feel magical instead of boring?"
@@ -85,8 +76,6 @@ _(Watch them debate whose fault it really was - it's therapeutic)_
 
 _(Ideas cross-pollinate and evolve)_
 
----
-
 ### Example 3: Technical Decision
 
 **You:** "Monolith or microservices for MVP?"
@@ -101,12 +90,6 @@ _(Ideas cross-pollinate and evolve)_
 
 _(Multiple perspectives reveal the right answer)_
 
-## Related Documentation
-
-- [Agents Reference](/docs/reference/agents/index.md) - Complete agent reference
-- [Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md) - Getting started with BMM
-- [Setup Party Mode](/docs/how-to/workflows/setup-party-mode.md) - How to use it
-
----
-
-_Better decisions through diverse perspectives. Welcome to party mode._
+:::tip[Better Decisions]
+Better decisions through diverse perspectives. Welcome to party mode.
+:::

docs/explanation/features/quick-flow.md

@@ -3,18 +3,14 @@ title: "Quick Spec Flow"
 description: Understanding Quick Spec Flow for rapid development in BMad Method
 ---
 
-
 Quick Spec Flow is a streamlined alternative to the full BMad Method for Quick Flow track projects. Instead of going through Product Brief → PRD → Architecture, you go straight to a context-aware technical specification and start coding.
 
-**Perfect for:** Bug fixes, small features, rapid prototyping, and quick enhancements
-
-**Time to implementation:** Minutes, not hours
-
----
+- **Perfect for:** Bug fixes, small features, rapid prototyping, and quick enhancements
+- **Time to implementation:** Minutes, not hours
 
 ## When to Use Quick Flow
 
-### ✅ Use Quick Flow when:
+### Use Quick Flow when:
 
 - Single bug fix or small enhancement
 - Small feature with clear scope (typically 1-15 stories)
@@ -22,16 +18,16 @@ Quick Spec Flow is a streamlined alternative to the full BMad Method for Quick F
 - Adding to existing brownfield codebase
 - You know exactly what you want to build
 
-### ❌ Use BMad Method or Enterprise when:
+### Use BMad Method or Enterprise when:
 
 - Building new products or major features
 - Need stakeholder alignment
 - Complex multi-team coordination
 - Requires extensive planning and architecture
 
-💡 **Not sure?** Run `workflow-init` to get a recommendation based on your project's needs!
-
----
+:::tip[Not Sure?]
+Run `workflow-init` to get a recommendation based on your project's needs.
+:::
 
 ## Quick Flow Overview
 
@@ -61,19 +57,15 @@ flowchart TD
     style DONE fill:#f9f,stroke:#333,stroke-width:3px
 ```
 
----
-
 ## What Makes It Quick
 
-- ✅ No Product Brief needed
-- ✅ No PRD needed
-- ✅ No Architecture doc needed
-- ✅ Auto-detects your stack
-- ✅ Auto-analyzes brownfield code
-- ✅ Auto-validates quality
-- ✅ Story context optional (tech-spec is comprehensive!)
-
----
+- No Product Brief needed
+- No PRD needed
+- No Architecture doc needed
+- Auto-detects your stack
+- Auto-analyzes brownfield code
+- Auto-validates quality
+- Story context optional (tech-spec is comprehensive)
 
 ## Smart Context Discovery
 
@@ -119,19 +111,15 @@ Should I follow these existing conventions? (yes/no)
 
 **You decide:** Conform to existing patterns or establish new standards!
 
----
-
 ## Auto-Validation
 
 Quick Spec Flow **automatically validates** everything:
 
-- ✅ Context gathering completeness
-- ✅ Definitiveness (no "use X or Y" statements)
-- ✅ Brownfield integration quality
-- ✅ Stack alignment
-- ✅ Implementation readiness
-
----
+- Context gathering completeness
+- Definitiveness (no "use X or Y" statements)
+- Brownfield integration quality
+- Stack alignment
+- Implementation readiness
 
 ## Comparison: Quick Flow vs Full BMM
 
@@ -145,25 +133,17 @@ Quick Spec Flow **automatically validates** everything:
 | **Validation**        | Auto-validates everything    | Manual validation steps            |
 | **Brownfield**        | Auto-analyzes and conforms   | Manual documentation required      |
 
----
-
 ## When to Graduate to BMad Method
 
 Start with Quick Flow, but switch to BMad Method when:
 
-- ❌ Project grows beyond initial scope
-- ❌ Multiple teams need coordination
-- ❌ Stakeholders need formal documentation
-- ❌ Product vision is unclear
-- ❌ Architectural decisions need deep analysis
-- ❌ Compliance/regulatory requirements exist
+- Project grows beyond initial scope
+- Multiple teams need coordination
+- Stakeholders need formal documentation
+- Product vision is unclear
+- Architectural decisions need deep analysis
+- Compliance/regulatory requirements exist
 
-💡 **Tip:** You can always run `workflow-init` later to transition from Quick Flow to BMad Method!
-
----
-
-## Related
-
-- [Quick Spec](/docs/how-to/workflows/quick-spec.md) - How to use Quick Flow
-- [Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md) - Getting started
-- [Four Phases](/docs/explanation/architecture/four-phases.md) - Understanding the full methodology
+:::tip[Transition Tip]
+You can always run `workflow-init` later to transition from Quick Flow to BMad Method.
+:::

docs/explanation/features/tea-overview.md

@@ -16,8 +16,6 @@ TEA was built to solve AI-generated tests that rot in review. For the problem st
 - **Mission:** Deliver actionable quality strategies, automation coverage, and gate decisions that scale with project complexity and compliance demands.
 - **Use When:** BMad Method or Enterprise track projects, integration risk is non-trivial, brownfield regression risk exists, or compliance/NFR evidence is required. (Quick Flow projects typically don't require TEA)
 
----
-
 ## Choose Your TEA Engagement Model
 
 BMad does not mandate TEA. There are five valid ways to use it (or skip it). Pick one intentionally.
@@ -25,10 +23,15 @@ BMad does not mandate TEA. There are five valid ways to use it (or skip it). Pic
 1. **No TEA**
    - Skip all TEA workflows. Use your existing team testing approach.
 
-2. **TEA-only (Standalone)**
+2. **TEA Solo (Standalone)**
    - Use TEA on a non-BMad project. Bring your own requirements, acceptance criteria, and environments.
    - Typical sequence: `*test-design` (system or epic) -> `*atdd` and/or `*automate` -> optional `*test-review` -> `*trace` for coverage and gate decisions.
-   - Run `*framework` or `*ci` only if you want TEA to scaffold the harness or pipeline.
+   - Run `*framework` or `*ci` only if you want TEA to scaffold the harness or pipeline; they work best after you decide the stack/architecture.
+
+**TEA Lite (Beginner Approach):**
+   - Simplest way to use TEA - just use `*automate` to test existing features.
+   - Perfect for learning TEA fundamentals in 30 minutes.
+   - See [TEA Lite Quickstart Tutorial](/docs/tutorials/getting-started/tea-lite-quickstart.md).
 
 3. **Integrated: Greenfield - BMad Method (Simple/Standard Work)**
    - Phase 3: system-level `*test-design`, then `*framework` and `*ci`.
@@ -50,10 +53,29 @@ BMad does not mandate TEA. There are five valid ways to use it (or skip it). Pic
 
 If you are unsure, default to the integrated path for your track and adjust later.
 
----
+## TEA Command Catalog
+
+| Command        | Primary Outputs                                                                               | Notes                                                | With Playwright MCP Enhancements                                                                                                     |
+| -------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `*framework`   | Playwright/Cypress scaffold, `.env.example`, `.nvmrc`, sample specs                           | Use when no production-ready harness exists          | -                                                                                                                                    |
+| `*ci`          | CI workflow, selective test scripts, secrets checklist                                        | Platform-aware (GitHub Actions default)              | -                                                                                                                                    |
+| `*test-design` | Combined risk assessment, mitigation plan, and coverage strategy                              | Risk scoring + optional exploratory mode             | **+ Exploratory**: Interactive UI discovery with browser automation (uncover actual functionality)                                   |
+| `*atdd`        | Failing acceptance tests + implementation checklist                                           | TDD red phase + optional recording mode              | **+ Recording**: UI selectors verified with live browser; API tests benefit from trace analysis                                      |
+| `*automate`    | Prioritized specs, fixtures, README/script updates, DoD summary                               | Optional healing/recording, avoid duplicate coverage | **+ Healing**: Visual debugging + trace analysis for test fixes; **+ Recording**: Verified selectors (UI) + network inspection (API) |
+| `*test-review` | Test quality review report with 0-100 score, violations, fixes                                | Reviews tests against knowledge base patterns        | -                                                                                                                                    |
+| `*nfr-assess`  | NFR assessment report with actions                                                            | Focus on security/performance/reliability            | -                                                                                                                                    |
+| `*trace`       | Phase 1: Coverage matrix, recommendations. Phase 2: Gate decision (PASS/CONCERNS/FAIL/WAIVED) | Two-phase workflow: traceability + gate decision     | -                                                                                                                                    |
 
 ## TEA Workflow Lifecycle
 
+**Phase Numbering Note:** BMad uses a 4-phase methodology with optional Phase 1 and a documentation prerequisite:
+
+- **Documentation** (Optional for brownfield): Prerequisite using `*document-project`
+- **Phase 1** (Optional): Discovery/Analysis (`*brainstorm`, `*research`, `*product-brief`)
+- **Phase 2** (Required): Planning (`*prd` creates PRD with FRs/NFRs)
+- **Phase 3** (Track-dependent): Solutioning (`*architecture` → `*test-design` (system-level) → `*create-epics-and-stories` → TEA: `*framework`, `*ci` → `*implementation-readiness`)
+- **Phase 4** (Required): Implementation (`*sprint-planning` → per-epic: `*test-design` → per-story: dev workflows)
+
 TEA integrates into the BMad development lifecycle during Solutioning (Phase 3) and Implementation (Phase 4):
 
 ```mermaid
@@ -136,66 +158,27 @@ graph TB
     style Waived fill:#9c27b0,stroke:#4a148c,stroke-width:3px,color:#000
 ```
 
-**Phase Numbering Note:** BMad uses a 4-phase methodology with optional Phase 1 and documentation prerequisite:
-
-- **Documentation** (Optional for brownfield): Prerequisite using `*document-project`
-- **Phase 1** (Optional): Discovery/Analysis (`*brainstorm`, `*research`, `*product-brief`)
-- **Phase 2** (Required): Planning (`*prd` creates PRD with FRs/NFRs)
-- **Phase 3** (Track-dependent): Solutioning (`*architecture` → `*test-design` (system-level) → `*create-epics-and-stories` → TEA: `*framework`, `*ci` → `*implementation-readiness`)
-- **Phase 4** (Required): Implementation (`*sprint-planning` → per-epic: `*test-design` → per-story: dev workflows)
-
 **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.
 - **Epic-level (Phase 4):** Run per-epic to produce `test-design-epic-N.md` (risk, priorities, coverage plan).
 
-Quick Flow track skips Phases 1 and 3.
+The Quick Flow track skips Phases 1 and 3.
 BMad Method and Enterprise use all phases based on project needs.
 When an ADR or architecture draft is produced, run `*test-design` in **system-level** mode before the implementation-readiness gate. This ensures the ADR has an attached testability review and ADR → test mapping. Keep the test-design updated if ADRs change.
 
----
+## Why TEA Is Different from Other BMM Agents
 
-## Why TEA is Different from Other BMM Agents
-
-TEA is the only BMM agent that operates in **multiple phases** (Phase 3 and Phase 4) and has its own **knowledge base architecture**.
-
-### Phase-Specific Agents (Standard Pattern)
-
-Most BMM agents work in a single phase:
-
-- **Phase 1 (Analysis)**: Analyst agent
-- **Phase 2 (Planning)**: PM agent
-- **Phase 3 (Solutioning)**: Architect agent
-- **Phase 4 (Implementation)**: SM, DEV agents
-
-### TEA: Multi-Phase Quality Agent (Unique Pattern)
-
-TEA is **the only agent that operates in multiple phases**:
-
-```
-Phase 1 (Analysis) → [TEA not typically used]
-    ↓
-Phase 2 (Planning) → [PM defines requirements - TEA not active]
-    ↓
-Phase 3 (Solutioning) → TEA: *framework, *ci (test infrastructure AFTER architecture)
-    ↓
-Phase 4 (Implementation) → TEA: *test-design (per epic: "how do I test THIS feature?")
-                        → TEA: *atdd, *automate, *test-review, *trace (per story)
-    ↓
-Epic/Release Gate → TEA: *nfr-assess, *trace Phase 2 (release decision)
-```
+TEA spans multiple phases (Phase 3, Phase 4, and the release gate). Most BMM agents operate in a single phase. That multi-phase role is paired with a dedicated testing knowledge base so standards stay consistent across projects.
 
 ### TEA's 8 Workflows Across Phases
 
-**Standard agents**: 1-3 workflows per phase
-**TEA**: 8 workflows across Phase 3, Phase 4, and Release Gate
-
-| Phase       | TEA Workflows                                             | Frequency        | Purpose                                        |
-| ----------- | --------------------------------------------------------- | ---------------- | ---------------------------------------------- |
-| **Phase 2** | (none)                                                    | -                | Planning phase - PM defines requirements       |
-| **Phase 3** | \*framework, \*ci                                         | Once per project | Setup test infrastructure AFTER architecture   |
-| **Phase 4** | \*test-design, \*atdd, \*automate, \*test-review, \*trace | Per epic/story   | Test planning per epic, then per-story testing |
-| **Release** | \*nfr-assess, \*trace (Phase 2: gate)                     | Per epic/release | Go/no-go decision                              |
+| Phase       | TEA Workflows                                             | Frequency        | Purpose                                                 |
+| ----------- | --------------------------------------------------------- | ---------------- | ------------------------------------------------------- |
+| **Phase 2** | (none)                                                    | -                | Planning phase - PM defines requirements                |
+| **Phase 3** | \*test-design (system-level), \*framework, \*ci           | Once per project | System testability review and test infrastructure setup |
+| **Phase 4** | \*test-design, \*atdd, \*automate, \*test-review, \*trace | Per epic/story   | Test planning per epic, then per-story testing          |
+| **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.
 
@@ -203,20 +186,17 @@ Epic/Release Gate → TEA: *nfr-assess, *trace Phase 2 (release decision)
 
 TEA uniquely requires:
 
-- **Extensive domain knowledge**: 30+ fragments covering test patterns, CI/CD, fixtures, quality practices, and optional playwright-utils integration
-- **Cross-cutting concerns**: Domain-specific testing patterns that apply across all BMad projects (vs project-specific artifacts like PRDs/stories)
-- **Optional integrations**: MCP capabilities (exploratory, verification) and playwright-utils support
+- **Extensive domain knowledge**: Test patterns, CI/CD, fixtures, and quality practices
+- **Cross-cutting concerns**: Standards that apply across all BMad projects (not just PRDs or stories)
+- **Optional integrations**: Playwright-utils and MCP enhancements
 
-This architecture enables TEA to maintain consistent, production-ready testing patterns across all BMad projects while operating across multiple development phases.
+This architecture lets TEA maintain consistent, production-ready testing patterns while operating across multiple phases.
 
----
-
-
-## High-Level Cheat Sheets
+## Track Cheat Sheets (Condensed)
 
 These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks** across the **4-Phase Methodology** (Phase 1: Analysis, Phase 2: Planning, Phase 3: Solutioning, Phase 4: Implementation).
 
-**Note:** Quick Flow projects typically don't require TEA (covered in Overview). These cheat sheets focus on BMad Method and Enterprise tracks where TEA adds value.
+**Note:** The Quick Flow track typically doesn't require TEA (covered in Overview). These cheat sheets focus on BMad Method and Enterprise tracks where TEA adds value.
 
 **Legend for Track Deltas:**
 
@@ -240,39 +220,15 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
 | **Phase 4**: Story Review  | Execute `*test-review` (optional), re-run `*trace`                | Address recommendations, update code/tests                                          | Quality report, refreshed coverage matrix                  |
 | **Phase 4**: Release Gate  | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2) | Confirm Definition of Done, share release notes                                     | Quality audit, Gate YAML + release summary                 |
 
-<details>
-<summary>Execution Notes</summary>
-
-- Run `*framework` only once per repo or when modern harness support is missing.
-- **Phase 3 (Solutioning)**: After architecture is complete, run `*framework` and `*ci` to setup test infrastructure based on architectural decisions.
-- **Phase 4 starts**: After solutioning is complete, sprint planning loads all epics.
-- **`*test-design` runs per-epic**: At the beginning of working on each epic, run `*test-design` to create a test plan for THAT specific epic/feature. Output: `test-design-epic-N.md`.
-- 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.
-- Clarification: `*test-review` is optional and only audits existing tests; run it after `*atdd` or `*automate` when you want a quality review, not as a required step.
-- Clarification: `*atdd` outputs are not auto-consumed; share the ATDD doc/tests with the dev workflow. `*trace` does not run `*atdd`—it evaluates existing artifacts for coverage and gate readiness.
-- Clarification: `*ci` is a one-time setup; recommended early (Phase 3 or before feature work), but it can be done later if it was skipped.
-
-</details>
-
-<details>
-<summary>Worked Example – “Nova CRM” Greenfield Feature</summary>
-
-1. **Planning (Phase 2):** Analyst runs `*product-brief`; PM executes `*prd` to produce PRD with FRs/NFRs.
-2. **Solutioning (Phase 3):** Architect completes `*architecture` for the new module; `*create-epics-and-stories` generates epics/stories based on architecture; TEA sets up test infrastructure via `*framework` and `*ci` based on architectural decisions; gate check validates planning completeness.
-3. **Sprint Start (Phase 4):** Scrum Master runs `*sprint-planning` to load all epics into sprint status.
-4. **Epic 1 Planning (Phase 4):** TEA runs `*test-design` to create test plan for Epic 1, producing `test-design-epic-1.md` with risk assessment.
-5. **Story Implementation (Phase 4):** For each story in Epic 1, SM generates story via `*create-story`; TEA optionally runs `*atdd`; Dev implements with guidance from failing tests.
-6. **Post-Dev (Phase 4):** TEA runs `*automate`, optionally `*test-review` to audit test quality, re-runs `*trace` to refresh coverage.
-7. **Release Gate:** TEA runs `*trace` with Phase 2 enabled to generate gate decision.
-
-</details>
+**Key notes:**
+- Run `*framework` and `*ci` once in Phase 3 after architecture.
+- Run `*test-design` per epic in Phase 4; use `*atdd` before dev when helpful.
+- Use `*trace` for gate decisions; `*test-review` is an optional audit.
 
 ### Brownfield - BMad Method or Enterprise (Simple or Complex)
 
 **Planning Tracks:** BMad Method or Enterprise Method
-**Use Case:** Existing codebases - simple additions (BMad Method) or complex enterprise requirements (Enterprise Method)
+**Use Case:** Existing codebases: simple additions (BMad Method) or complex enterprise requirements (Enterprise Method)
 
 **🔄 Brownfield Deltas from Greenfield:**
 
@@ -293,31 +249,10 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
 | **Phase 4**: Story Review         | Apply `*test-review` (optional), re-run `*trace`, ➕ `*nfr-assess` if needed | Resolve gaps, update docs/tests                                                     | Quality report, refreshed coverage matrix, NFR report                  |
 | **Phase 4**: Release Gate         | (Optional) `*test-review` for final audit, Run `*trace` (Phase 2)           | Capture sign-offs, share release notes                                              | Quality audit, Gate YAML + release summary                             |
 
-<details>
-<summary>Execution Notes</summary>
-
-- Lead with `*trace` during Planning (Phase 2) to baseline existing test coverage before architecture work begins.
-- **Phase 3 (Solutioning)**: After architecture is complete, run `*framework` and `*ci` to modernize test infrastructure. For brownfield, framework may need to integrate with or replace existing test setup.
-- **Phase 4 starts**: After solutioning is complete and sprint planning loads all epics.
-- **`*test-design` runs per-epic**: At the beginning of working on each epic, run `*test-design` to identify regression hotspots, integration risks, and mitigation strategies for THAT specific epic/feature. Output: `test-design-epic-N.md`.
-- 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.
-
-</details>
-
-<details>
-<summary>Worked Example – “Atlas Payments” Brownfield Story</summary>
-
-1. **Planning (Phase 2):** PM executes `*prd` to create PRD with FRs/NFRs; TEA runs `*trace` to baseline existing coverage.
-2. **Solutioning (Phase 3):** Architect triggers `*architecture` capturing legacy payment flows and integration architecture; `*create-epics-and-stories` generates Epic 1 (Payment Processing) based on architecture; TEA sets up `*framework` and `*ci` based on architectural decisions; gate check validates planning.
-3. **Sprint Start (Phase 4):** Scrum Master runs `*sprint-planning` to load Epic 1 into sprint status.
-4. **Epic 1 Planning (Phase 4):** TEA runs `*test-design` for Epic 1 (Payment Processing), producing `test-design-epic-1.md` that flags settlement edge cases, regression hotspots, and mitigation plans.
-5. **Story Implementation (Phase 4):** For each story in Epic 1, SM generates story via `*create-story`; TEA runs `*atdd` producing failing Playwright specs; Dev implements with guidance from tests and checklist.
-6. **Post-Dev (Phase 4):** TEA applies `*automate`, optionally `*test-review` to audit test quality, re-runs `*trace` to refresh coverage.
-7. **Release Gate:** TEA performs `*nfr-assess` to validate SLAs, runs `*trace` with Phase 2 enabled to generate gate decision (PASS/CONCERNS/FAIL).
-
-</details>
+**Key notes:**
+- Start with `*trace` in Phase 2 to baseline coverage.
+- Focus `*test-design` on regression hotspots and integration risk.
+- Run `*nfr-assess` before the gate if it wasn't done earlier.
 
 ### Greenfield - Enterprise Method (Enterprise/Compliance Work)
 
@@ -341,111 +276,61 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
 | **Phase 4**: Story Dev     | (Optional) `*atdd`, `*automate`, `*test-review`, `*trace` per story     | SM `*create-story`, DEV implements                                                  | Tests, fixtures, quality reports, coverage matrices                |
 | **Phase 4**: Release Gate  | Final `*test-review` audit, Run `*trace` (Phase 2), 📦 archive artifacts | Capture sign-offs, 📦 compliance evidence                                            | Quality audit, updated assessments, gate YAML, 📦 audit trail       |
 
-<details>
-<summary>Execution Notes</summary>
+**Key notes:**
+- Run `*nfr-assess` early in Phase 2.
+- `*test-design` emphasizes compliance, security, and performance alignment.
+- Archive artifacts at the release gate for audits.
 
-- `*nfr-assess` runs early in Planning (Phase 2) to capture compliance, security, and performance requirements upfront.
-- **Phase 3 (Solutioning)**: After architecture is complete, run `*framework` and `*ci` with enterprise-grade configurations (selective testing, burn-in jobs, caching, notifications).
-- **Phase 4 starts**: After solutioning is complete and sprint planning loads all epics.
-- **`*test-design` runs per-epic**: At the beginning of working on each epic, run `*test-design` to create an enterprise-focused test plan for THAT specific epic, ensuring alignment with security architecture, performance targets, and compliance requirements. Output: `test-design-epic-N.md`.
-- Use `*atdd` for stories when feasible so acceptance tests can lead implementation.
-- Use `*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); archive artifacts for compliance audits.
+**Related how-to guides:**
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md)
+- [How to Set Up a Test Framework](/docs/how-to/workflows/setup-test-framework.md)
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md)
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md)
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md)
+- [How to Set Up CI Pipeline](/docs/how-to/workflows/setup-ci.md)
+- [How to Run NFR Assessment](/docs/how-to/workflows/run-nfr-assess.md)
+- [How to Run Trace](/docs/how-to/workflows/run-trace.md)
 
-</details>
+## Deep Dive Concepts
 
-<details>
-<summary>Worked Example – “Helios Ledger” Enterprise Release</summary>
+Want to understand TEA principles and patterns in depth?
 
-1. **Planning (Phase 2):** Analyst runs `*research` and `*product-brief`; PM completes `*prd` creating PRD with FRs/NFRs; TEA runs `*nfr-assess` to establish NFR targets.
-2. **Solutioning (Phase 3):** Architect completes `*architecture` with enterprise considerations; `*create-epics-and-stories` generates epics/stories based on architecture; TEA sets up `*framework` and `*ci` with enterprise-grade configurations based on architectural decisions; gate check validates planning completeness.
-3. **Sprint Start (Phase 4):** Scrum Master runs `*sprint-planning` to load all epics into sprint status.
-4. **Per-Epic (Phase 4):** For each epic, TEA runs `*test-design` to create epic-specific test plan (e.g., `test-design-epic-1.md`, `test-design-epic-2.md`) with compliance-focused risk assessment.
-5. **Per-Story (Phase 4):** For each story, TEA uses `*atdd`, `*automate`, `*test-review`, and `*trace`; Dev teams iterate on the findings.
-6. **Release Gate:** 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.
+**Core Principles:**
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Probability × impact scoring, P0-P3 priorities
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - Definition of Done, determinism, isolation
+- [Knowledge Base System](/docs/explanation/tea/knowledge-base-system.md) - Context engineering with tea-index.csv
 
-</details>
+**Technical Patterns:**
+- [Fixture Architecture](/docs/explanation/tea/fixture-architecture.md) - Pure function → fixture → composition
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Eliminating flakiness with intercept-before-navigate
 
----
+**Engagement & Strategy:**
+- [Engagement Models](/docs/explanation/tea/engagement-models.md) - TEA Lite, TEA Solo, TEA Integrated (5 models explained)
 
-## TEA Command Catalog
+**Philosophy:**
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - **Start here to understand WHY TEA exists** - The problem with AI-generated tests and TEA's three-part solution
 
-| Command        | Primary Outputs                                                                               | Notes                                                | With Playwright MCP Enhancements                                                                             |
-| -------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
-| `*framework`   | Playwright/Cypress scaffold, `.env.example`, `.nvmrc`, sample specs                           | Use when no production-ready harness exists          | -                                                                                                            |
-| `*ci`          | CI workflow, selective test scripts, secrets checklist                                        | Platform-aware (GitHub Actions default)              | -                                                                                                            |
-| `*test-design` | Combined risk assessment, mitigation plan, and coverage strategy                              | Risk scoring + optional exploratory mode             | **+ Exploratory**: Interactive UI discovery with browser automation (uncover actual functionality)           |
-| `*atdd`        | Failing acceptance tests + implementation checklist                                           | TDD red phase + optional recording mode              | **+ Recording**: AI generation verified with live browser (accurate selectors from real DOM)                 |
-| `*automate`    | 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` | Test quality review report with 0-100 score, violations, fixes                                | Reviews tests against knowledge base patterns        | -                                                                                                            |
-| `*nfr-assess`  | NFR assessment report with actions                                                            | Focus on security/performance/reliability            | -                                                                                                            |
-| `*trace`       | Phase 1: Coverage matrix, recommendations. Phase 2: Gate decision (PASS/CONCERNS/FAIL/WAIVED) | Two-phase workflow: traceability + gate decision     | -                                                                                                            |
+## Optional Integrations
 
----
+### Playwright Utils (`@seontechnologies/playwright-utils`)
 
-## Playwright Utils Integration
+Production-ready fixtures and utilities that enhance TEA workflows.
 
-TEA optionally integrates with `@seontechnologies/playwright-utils`, an open-source library providing fixture-based utilities for Playwright tests. This integration enhances TEA's test generation and review workflows with production-ready patterns.
+- Install: `npm install -D @seontechnologies/playwright-utils`
+> Note: Playwright Utils is enabled via the installer. Only set `tea_use_playwright_utils` in `_bmad/bmm/config.yaml` if you need to override the installer choice.
+- Impacts: `*framework`, `*atdd`, `*automate`, `*test-review`, `*ci`
+- Utilities include: api-request, auth-session, network-recorder, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor, fixtures-composition
 
-<details>
-<summary><strong>Installation & Configuration</strong></summary>
+### Playwright MCP Enhancements
 
-**Package**: `@seontechnologies/playwright-utils` ([npm](https://www.npmjs.com/package/@seontechnologies/playwright-utils) | [GitHub](https://github.com/seontechnologies/playwright-utils))
-
-**Install**: `npm install -D @seontechnologies/playwright-utils`
-
-**Enable during BMAD installation** by answering "Yes" when prompted, or manually set `tea_use_playwright_utils: true` in `_bmad/bmm/config.yaml`.
-
-**To disable**: Set `tea_use_playwright_utils: false` in `_bmad/bmm/config.yaml`.
-
-</details>
-
-<details>
-<summary><strong>How Playwright Utils Enhances TEA Workflows</strong></summary>
-
-1. `*framework`:
-   - Default: Basic Playwright scaffold
-   - **+ playwright-utils**: Scaffold with api-request, network-recorder, auth-session, burn-in, network-error-monitor fixtures pre-configured
-
-   Benefit: Production-ready patterns from day one
-
-2. `*automate`, `*atdd`:
-   - Default: Standard test patterns
-   - **+ playwright-utils**: Tests using api-request (schema validation), intercept-network-call (mocking), recurse (polling), log (structured logging), file-utils (CSV/PDF)
-
-   Benefit: Advanced patterns without boilerplate
-
-3. `*test-review`:
-   - Default: Reviews against core knowledge base (22 fragments)
-   - **+ playwright-utils**: Reviews against expanded knowledge base (33 fragments: 22 core + 11 playwright-utils)
-
-   Benefit: Reviews include fixture composition, auth patterns, network recording best practices
-
-4. `*ci`:
-   - Default: Standard CI workflow
-   - **+ playwright-utils**: CI workflow with burn-in script (smart test selection) and network-error-monitor integration
-
-   Benefit: Faster CI feedback, HTTP error detection
-
-**Utilities available** (10 total): api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor, fixtures-composition
-
-</details>
-
----
-
-## Playwright MCP Enhancements
-
-TEA can leverage Playwright MCP servers to enhance test generation with live browser verification. MCP provides interactive capabilities on top of TEA's default AI-based approach.
-
-<details>
-<summary><strong>MCP Server Configuration</strong></summary>
+Live browser verification for test design and automation.
 
 **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`)
 
-**Config example**:
+**Configuration example**:
 
 ```json
 {
@@ -462,36 +347,64 @@ TEA can leverage Playwright MCP servers to enhance test generation with live bro
 }
 ```
 
-**To disable**: Set `tea_use_mcp_enhancements: false` in `_bmad/bmm/config.yaml` OR remove MCPs from IDE config.
+- Helps `*test-design` validate actual UI behavior.
+- Helps `*atdd` and `*automate` verify selectors against the live DOM.
+- Enhances healing with `browser_snapshot`, console, network, and locator tools.
 
-</details>
-
-<details>
-<summary><strong>How MCP Enhances TEA Workflows</strong></summary>
-
-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` (healing mode):
-   - 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
-
-</details>
+**To disable**: set `tea_use_mcp_enhancements: false` in `_bmad/bmm/config.yaml` or remove MCPs from IDE config.
 
 ---
 
-## Related Documentation
+## Complete TEA Documentation Navigation
 
-- [Setup Test Framework](/docs/how-to/workflows/setup-test-framework.md) - How to set up testing infrastructure
-- [Run Test Design](/docs/how-to/workflows/run-test-design.md) - Creating test plans
+### Start Here
+
+**New to TEA? Start with the tutorial:**
+- [TEA Lite Quickstart Tutorial](/docs/tutorials/getting-started/tea-lite-quickstart.md) - 30-minute beginner guide using TodoMVC
+
+### Workflow Guides (Task-Oriented)
+
+**All 8 TEA workflows with step-by-step instructions:**
+1. [How to Set Up a Test Framework with TEA](/docs/how-to/workflows/setup-test-framework.md) - Scaffold Playwright or Cypress
+2. [How to Set Up CI Pipeline with TEA](/docs/how-to/workflows/setup-ci.md) - Configure CI/CD with selective testing
+3. [How to Run Test Design with TEA](/docs/how-to/workflows/run-test-design.md) - Risk-based test planning (system or epic)
+4. [How to Run ATDD with TEA](/docs/how-to/workflows/run-atdd.md) - Generate failing tests before implementation
+5. [How to Run Automate with TEA](/docs/how-to/workflows/run-automate.md) - Expand test coverage after implementation
+6. [How to Run Test Review with TEA](/docs/how-to/workflows/run-test-review.md) - Audit test quality (0-100 scoring)
+7. [How to Run NFR Assessment with TEA](/docs/how-to/workflows/run-nfr-assess.md) - Validate non-functional requirements
+8. [How to Run Trace with TEA](/docs/how-to/workflows/run-trace.md) - Coverage traceability + gate decisions
+
+### Customization & Integration
+
+**Optional enhancements to TEA workflows:**
+- [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) - Production-ready fixtures and 9 utilities
+- [Enable TEA MCP Enhancements](/docs/how-to/customization/enable-tea-mcp-enhancements.md) - Live browser verification, visual debugging
+
+### Use-Case Guides
+
+**Specialized guidance for specific contexts:**
+- [Using TEA with Existing Tests (Brownfield)](/docs/how-to/brownfield/use-tea-with-existing-tests.md) - Incremental improvement, regression hotspots, baseline coverage
+- [Running TEA for Enterprise](/docs/how-to/brownfield/use-tea-for-enterprise.md) - Compliance, NFR assessment, audit trails, SOC 2/HIPAA
+
+### Concept Deep Dives (Understanding-Oriented)
+
+**Understand the principles and patterns:**
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Probability × impact scoring, P0-P3 priorities, mitigation strategies
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - Definition of Done, determinism, isolation, explicit assertions
+- [Fixture Architecture](/docs/explanation/tea/fixture-architecture.md) - Pure function → fixture → composition pattern
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Intercept-before-navigate, eliminating flakiness
+- [Knowledge Base System](/docs/explanation/tea/knowledge-base-system.md) - Context engineering with tea-index.csv, 33 fragments
+- [Engagement Models](/docs/explanation/tea/engagement-models.md) - TEA Lite, TEA Solo, TEA Integrated (5 models explained)
+
+### Philosophy & Design
+
+**Why TEA exists and how it works:**
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - **Start here to understand WHY** - The problem with AI-generated tests and TEA's three-part solution
+
+### Reference (Quick Lookup)
+
+**Factual information for quick reference:**
+- [TEA Command Reference](/docs/reference/tea/commands.md) - All 8 workflows: inputs, outputs, phases, frequency
+- [TEA Configuration Reference](/docs/reference/tea/configuration.md) - Config options, file locations, setup examples
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - 33 fragments categorized and explained
+- [Glossary - TEA Section](/docs/reference/glossary/index.md#test-architect-tea-concepts) - 20 TEA-specific terms defined

docs/explanation/features/web-bundles.md

@@ -2,12 +2,11 @@
 title: "Web Bundles"
 ---
 
-
 Use BMad agents in Gemini Gems and Custom GPTs.
 
-## Status
-
-> **Note:** The Web Bundling Feature is being rebuilt from the ground up. Current v6 bundles may be incomplete or missing functionality.
+:::caution[Status]
+The Web Bundling Feature is being rebuilt from the ground up. Current v6 bundles may be incomplete or missing functionality.
+:::
 
 ## What Are Web Bundles?
 

docs/explanation/game-dev/agents.md

@@ -1,410 +0,0 @@
----
-title: "BMGD Agents Guide"
----
-
-
-Complete reference for BMGD's six specialized game development agents.
-
----
-
-## Agent Overview
-
-BMGD provides six agents, each with distinct expertise:
-
-| Agent                    | Name             | Role                                                        | Phase Focus |
-| ------------------------ | ---------------- | ----------------------------------------------------------- | ----------- |
-| 🎲 **Game Designer**     | Samus Shepard    | Lead Game Designer + Creative Vision Architect              | Phases 1-2  |
-| 🏛️ **Game Architect**    | Cloud Dragonborn | Principal Game Systems Architect + Technical Director       | Phase 3     |
-| 🕹️ **Game Developer**    | Link Freeman     | Senior Game Developer + Technical Implementation Specialist | Phase 4     |
-| 🎯 **Game Scrum Master** | Max              | Game Development Scrum Master + Sprint Orchestrator         | Phase 4     |
-| 🧪 **Game QA**           | GLaDOS           | Game QA Architect + Test Automation Specialist              | All Phases  |
-| 🎮 **Game Solo Dev**     | Indie            | Elite Indie Game Developer + Quick Flow Specialist          | All Phases  |
-
----
-
-## 🎲 Game Designer (Samus Shepard)
-
-### Role
-
-Lead Game Designer + Creative Vision Architect
-
-### Identity
-
-Veteran designer with 15+ years crafting AAA and indie hits. Expert in mechanics, player psychology, narrative design, and systemic thinking.
-
-### Communication Style
-
-Talks like an excited streamer - enthusiastic, asks about player motivations, celebrates breakthroughs with "Let's GOOO!"
-
-### Core Principles
-
-- Design what players want to FEEL, not what they say they want
-- Prototype fast - one hour of playtesting beats ten hours of discussion
-- Every mechanic must serve the core fantasy
-
-### When to Use
-
-- Brainstorming game ideas
-- Creating Game Briefs
-- Designing GDDs
-- Developing narrative design
-
-### Available Commands
-
-| Command                | Description                      |
-| ---------------------- | -------------------------------- |
-| `workflow-status`      | Check project status             |
-| `brainstorm-game`      | Guided game ideation             |
-| `create-game-brief`    | Create Game Brief                |
-| `create-gdd`           | Create Game Design Document      |
-| `narrative`            | Create Narrative Design Document |
-| `quick-prototype`      | Rapid prototyping (IDE only)     |
-| `party-mode`           | Multi-agent collaboration        |
-| `advanced-elicitation` | Deep exploration (web only)      |
-
----
-
-## 🏛️ Game Architect (Cloud Dragonborn)
-
-### Role
-
-Principal Game Systems Architect + Technical Director
-
-### Identity
-
-Master architect with 20+ years shipping 30+ titles. Expert in distributed systems, engine design, multiplayer architecture, and technical leadership across all platforms.
-
-### Communication Style
-
-Speaks like a wise sage from an RPG - calm, measured, uses architectural metaphors about building foundations and load-bearing walls.
-
-### Core Principles
-
-- Architecture is about delaying decisions until you have enough data
-- Build for tomorrow without over-engineering today
-- Hours of planning save weeks of refactoring hell
-- Every system must handle the hot path at 60fps
-
-### When to Use
-
-- Planning technical architecture
-- Making engine/framework decisions
-- Designing game systems
-- Course correction during development
-
-### Available Commands
-
-| Command                | Description                           |
-| ---------------------- | ------------------------------------- |
-| `workflow-status`      | Check project status                  |
-| `create-architecture`  | Create Game Architecture              |
-| `correct-course`       | Course correction analysis (IDE only) |
-| `party-mode`           | Multi-agent collaboration             |
-| `advanced-elicitation` | Deep exploration (web only)           |
-
----
-
-## 🕹️ Game Developer (Link Freeman)
-
-### Role
-
-Senior Game Developer + Technical Implementation Specialist
-
-### Identity
-
-Battle-hardened dev with expertise in Unity, Unreal, and custom engines. Ten years shipping across mobile, console, and PC. Writes clean, performant code.
-
-### Communication Style
-
-Speaks like a speedrunner - direct, milestone-focused, always optimizing for the fastest path to ship.
-
-### Core Principles
-
-- 60fps is non-negotiable
-- Write code designers can iterate without fear
-- Ship early, ship often, iterate on player feedback
-- Red-green-refactor: tests first, implementation second
-
-### When to Use
-
-- Implementing stories
-- Code reviews
-- Performance optimization
-- Completing story work
-
-### Available Commands
-
-| Command                | Description                     |
-| ---------------------- | ------------------------------- |
-| `workflow-status`      | Check sprint progress           |
-| `dev-story`            | Implement story tasks           |
-| `code-review`          | Perform code review             |
-| `quick-dev`            | Flexible development (IDE only) |
-| `quick-prototype`      | Rapid prototyping (IDE only)    |
-| `party-mode`           | Multi-agent collaboration       |
-| `advanced-elicitation` | Deep exploration (web only)     |
-
----
-
-## 🎯 Game Scrum Master (Max)
-
-### Role
-
-Game Development Scrum Master + Sprint Orchestrator
-
-### Identity
-
-Certified Scrum Master specializing in game dev workflows. Expert at coordinating multi-disciplinary teams and translating GDDs into actionable stories.
-
-### Communication Style
-
-Talks in game terminology - milestones are save points, handoffs are level transitions, blockers are boss fights.
-
-### Core Principles
-
-- Every sprint delivers playable increments
-- Clean separation between design and implementation
-- Keep the team moving through each phase
-- Stories are single source of truth for implementation
-
-### When to Use
-
-- Sprint planning and management
-- Creating epic tech specs
-- Writing story drafts
-- Assembling story context
-- Running retrospectives
-- Handling course corrections
-
-### Available Commands
-
-| Command                 | Description                                 |
-| ----------------------- | ------------------------------------------- |
-| `workflow-status`       | Check project status                        |
-| `sprint-planning`       | Generate/update sprint status               |
-| `sprint-status`         | View sprint progress, get next action       |
-| `create-story`          | Create story (marks ready-for-dev directly) |
-| `validate-create-story` | Validate story draft                        |
-| `epic-retrospective`    | Facilitate retrospective                    |
-| `correct-course`        | Navigate significant changes                |
-| `party-mode`            | Multi-agent collaboration                   |
-| `advanced-elicitation`  | Deep exploration (web only)                 |
-
----
-
-## 🧪 Game QA (GLaDOS)
-
-### Role
-
-Game QA Architect + Test Automation Specialist
-
-### Identity
-
-Senior QA architect with 12+ years in game testing across Unity, Unreal, and Godot. Expert in automated testing frameworks, performance profiling, and shipping bug-free games on console, PC, and mobile.
-
-### Communication Style
-
-Speaks like a quality guardian - methodical, data-driven, but understands that "feel" matters in games. Uses metrics to back intuition. "Trust, but verify with tests."
-
-### Core Principles
-
-- Test what matters: gameplay feel, performance, progression
-- Automated tests catch regressions, humans catch fun problems
-- Every shipped bug is a process failure, not a people failure
-- Flaky tests are worse than no tests - they erode trust
-- Profile before optimize, test before ship
-
-### When to Use
-
-- Setting up test frameworks
-- Designing test strategies
-- Creating automated tests
-- Planning playtesting sessions
-- Performance testing
-- Reviewing test coverage
-
-### Available Commands
-
-| Command                | Description                                         |
-| ---------------------- | --------------------------------------------------- |
-| `workflow-status`      | Check project status                                |
-| `test-framework`       | Initialize game test framework (Unity/Unreal/Godot) |
-| `test-design`          | Create comprehensive game test scenarios            |
-| `automate`             | Generate automated game tests                       |
-| `playtest-plan`        | Create structured playtesting plan                  |
-| `performance-test`     | Design performance testing strategy                 |
-| `test-review`          | Review test quality and coverage                    |
-| `party-mode`           | Multi-agent collaboration                           |
-| `advanced-elicitation` | Deep exploration (web only)                         |
-
-### Knowledge Base
-
-GLaDOS has access to a comprehensive game testing knowledge base (`gametest/qa-index.csv`) including:
-
-**Engine-Specific Testing:**
-
-- Unity Test Framework (Edit Mode, Play Mode)
-- Unreal Automation and Gauntlet
-- Godot GUT (Godot Unit Test)
-
-**Game-Specific Testing:**
-
-- Playtesting fundamentals
-- Balance testing
-- Save system testing
-- Multiplayer/network testing
-- Input testing
-- Platform certification (TRC/XR)
-- Localization testing
-
-**General QA:**
-
-- QA automation strategies
-- Performance testing
-- Regression testing
-- Smoke testing
-- Test prioritization (P0-P3)
-
----
-
-## 🎮 Game Solo Dev (Indie)
-
-### Role
-
-Elite Indie Game Developer + Quick Flow Specialist
-
-### Identity
-
-Battle-hardened solo game developer who ships complete games from concept to launch. Expert in Unity, Unreal, and Godot, having shipped titles across mobile, PC, and console. Lives and breathes the Quick Flow workflow - prototyping fast, iterating faster, and shipping before the hype dies.
-
-### Communication Style
-
-Direct, confident, and gameplay-focused. Uses dev slang, thinks in game feel and player experience. Every response moves the game closer to ship. "Does it feel good? Ship it."
-
-### Core Principles
-
-- Prototype fast, fail fast, iterate faster
-- A playable build beats a perfect design doc
-- 60fps is non-negotiable - performance is a feature
-- The core loop must be fun before anything else matters
-- Ship early, playtest often
-
-### When to Use
-
-- Solo game development
-- Rapid prototyping
-- Quick iteration without full team workflow
-- Indie projects with tight timelines
-- When you want to handle everything yourself
-
-### Available Commands
-
-| Command            | Description                                            |
-| ------------------ | ------------------------------------------------------ |
-| `quick-prototype`  | Rapid prototype to test if a mechanic is fun           |
-| `quick-dev`        | Implement features end-to-end with game considerations |
-| `quick-spec`       | Create implementation-ready technical spec             |
-| `code-review`      | Review code quality                                    |
-| `test-framework`   | Set up automated testing                               |
-| `party-mode`       | Bring in specialists when needed                       |
-
-### Quick Flow vs Full BMGD
-
-Use **Game Solo Dev** when:
-
-- You're working alone or in a tiny team
-- Speed matters more than process
-- You want to skip the full planning phases
-- You're prototyping or doing game jams
-
-Use **Full BMGD workflow** when:
-
-- You have a larger team
-- The project needs formal documentation
-- You're working with stakeholders/publishers
-- Long-term maintainability is critical
-
----
-
-## Agent Selection Guide
-
-### By Phase
-
-| Phase                          | Primary Agent     | Secondary Agent   |
-| ------------------------------ | ----------------- | ----------------- |
-| 1: Preproduction               | Game Designer     | -                 |
-| 2: Design                      | Game Designer     | -                 |
-| 3: Technical                   | Game Architect    | Game QA           |
-| 4: Production (Planning)       | Game Scrum Master | Game Architect    |
-| 4: Production (Implementation) | Game Developer    | Game Scrum Master |
-| Testing (Any Phase)            | Game QA           | Game Developer    |
-
-### By Task
-
-| Task                             | Best Agent        |
-| -------------------------------- | ----------------- |
-| "I have a game idea"             | Game Designer     |
-| "Help me design my game"         | Game Designer     |
-| "How should I build this?"       | Game Architect    |
-| "What's the technical approach?" | Game Architect    |
-| "Plan our sprints"               | Game Scrum Master |
-| "Create implementation stories"  | Game Scrum Master |
-| "Build this feature"             | Game Developer    |
-| "Review this code"               | Game Developer    |
-| "Set up testing framework"       | Game QA           |
-| "Create test plan"               | Game QA           |
-| "Test performance"               | Game QA           |
-| "Plan a playtest"                | Game QA           |
-| "I'm working solo"               | Game Solo Dev     |
-| "Quick prototype this idea"      | Game Solo Dev     |
-| "Ship this feature fast"         | Game Solo Dev     |
-
----
-
-## Multi-Agent Collaboration
-
-### Party Mode
-
-All agents have access to `party-mode`, which brings multiple agents together for complex decisions. Use this when:
-
-- A decision spans multiple domains (design + technical)
-- You want diverse perspectives
-- You're stuck and need fresh ideas
-
-### Handoffs
-
-Agents naturally hand off to each other:
-
-```
-Game Designer → Game Architect → Game Scrum Master → Game Developer
-    ↓                ↓                  ↓                  ↓
-  GDD          Architecture      Sprint/Stories      Implementation
-                     ↓                                     ↓
-                 Game QA ←──────────────────────────── Game QA
-                     ↓                                     ↓
-              Test Strategy                         Automated Tests
-```
-
-Game QA integrates at multiple points:
-
-- After Architecture: Define test strategy
-- During Implementation: Create automated tests
-- Before Release: Performance and certification testing
-
----
-
-## Project Context
-
-All agents share the principle:
-
-> "Find if this exists, if it does, always treat it as the bible I plan and execute against: `**/project-context.md`"
-
-The `project-context.md` file (if present) serves as the authoritative source for project decisions and constraints.
-
----
-
-## Next Steps
-
-- **[Quick Start Guide](/docs/tutorials/getting-started/quick-start-bmgd.md)** - Get started with BMGD
-- **[Workflows Guide](/docs/reference/workflows/index.md)** - Detailed workflow reference
-- **[Game Types Guide](/docs/explanation/game-dev/game-types.md)** - Game type templates

docs/explanation/game-dev/bmgd-vs-bmm.md

@@ -1,150 +0,0 @@
----
-title: "BMGD vs BMM"
-description: Understanding the differences between BMGD and BMM
----
-
-
-BMGD (BMad Game Development) extends BMM (BMad Method) with game-specific capabilities. This page explains the key differences.
-
----
-
-## Quick Comparison
-
-| Aspect         | BMM                                   | BMGD                                                                     |
-| -------------- | ------------------------------------- | ------------------------------------------------------------------------ |
-| **Focus**      | General software                      | Game development                                                         |
-| **Agents**     | PM, Architect, Dev, SM, TEA, Solo Dev | Game Designer, Game Dev, Game Architect, Game SM, Game QA, Game Solo Dev |
-| **Planning**   | PRD, Tech Spec                        | Game Brief, GDD                                                          |
-| **Types**      | N/A                                   | 24 game type templates                                                   |
-| **Narrative**  | N/A                                   | Full narrative workflow                                                  |
-| **Testing**    | Web-focused                           | Engine-specific (Unity, Unreal, Godot)                                   |
-| **Production** | BMM workflows                         | BMM workflows with game overrides                                        |
-
----
-
-## Agent Differences
-
-### BMM Agents
-- PM (Product Manager)
-- Architect
-- DEV (Developer)
-- SM (Scrum Master)
-- TEA (Test Architect)
-- Quick Flow Solo Dev
-
-### BMGD Agents
-- Game Designer
-- Game Developer
-- Game Architect
-- Game Scrum Master
-- Game QA
-- Game Solo Dev
-
-BMGD agents understand game-specific concepts like:
-- Game mechanics and balance
-- Player psychology
-- Engine-specific patterns
-- Playtesting and QA
-
----
-
-## Planning Documents
-
-### BMM Planning
-- **Product Brief** → **PRD** → **Architecture**
-- Focus: Software requirements, user stories, system design
-
-### BMGD Planning
-- **Game Brief** → **GDD** → **Architecture**
-- Focus: Game vision, mechanics, narrative, player experience
-
-The GDD (Game Design Document) includes:
-- Core gameplay loop
-- Mechanics and systems
-- Progression and balance
-- Art and audio direction
-- Genre-specific sections
-
----
-
-## Game Type Templates
-
-BMGD includes 24 game type templates that auto-configure GDD sections:
-
-- Action, Adventure, Puzzle
-- RPG, Strategy, Simulation
-- Sports, Racing, Fighting
-- Horror, Platformer, Shooter
-- And more...
-
-Each template provides:
-- Genre-specific GDD sections
-- Relevant mechanics patterns
-- Testing considerations
-- Common pitfalls to avoid
-
----
-
-## Narrative Support
-
-BMGD includes full narrative workflow for story-driven games:
-
-- **Narrative Design** workflow
-- Story structure templates
-- Character development
-- World-building guidelines
-- Dialogue systems
-
-BMM has no equivalent for narrative design.
-
----
-
-## Testing Differences
-
-### BMM Testing (TEA)
-- Web-focused (Playwright, Cypress)
-- API testing
-- E2E for web applications
-
-### BMGD Testing (Game QA)
-- Engine-specific frameworks (Unity, Unreal, Godot)
-- Gameplay testing
-- Performance profiling
-- Playtest planning
-- Balance validation
-
----
-
-## Production Workflow
-
-BMGD production workflows **inherit from BMM** and add game-specific:
-- Checklists
-- Templates
-- Quality gates
-- Engine-specific considerations
-
-This means you get all of BMM's implementation structure plus game-specific enhancements.
-
----
-
-## When to Use Each
-
-### Use BMM when:
-- Building web applications
-- Creating APIs and services
-- Developing mobile apps (non-game)
-- Any general software project
-
-### Use BMGD when:
-- Building video games
-- Creating interactive experiences
-- Game prototyping
-- Game jams
-
----
-
-## Related
-
-- [BMGD Overview](/docs/explanation/game-dev/index.md) - Getting started with BMGD
-- [Game Types Guide](/docs/explanation/game-dev/game-types.md) - Understanding game templates
-- [Quick Start BMGD](/docs/tutorials/getting-started/quick-start-bmgd.md) - Tutorial

docs/explanation/game-dev/game-types.md

@@ -1,506 +0,0 @@
----
-title: "BMGD Game Types Guide"
----
-
-
-Reference for selecting and using BMGD's 24 supported game type templates.
-
----
-
-## Overview
-
-When creating a GDD, BMGD offers game type templates that provide genre-specific sections. This ensures your design document covers mechanics and systems relevant to your game's genre.
-
----
-
-## Supported Game Types
-
-### Action & Combat
-
-#### Action Platformer
-
-**Tags:** action, platformer, combat, movement
-
-Side-scrolling or 3D platforming with combat mechanics. Think Hollow Knight, Celeste with combat, or Mega Man.
-
-**GDD sections added:**
-
-- Movement systems (jumps, dashes, wall mechanics)
-- Combat mechanics (melee/ranged, combos)
-- Level design patterns
-- Boss design
-
----
-
-#### Shooter
-
-**Tags:** shooter, combat, aiming, fps, tps
-
-Projectile combat with aiming mechanics. Covers FPS, TPS, and arena shooters.
-
-**GDD sections added:**
-
-- Weapon systems
-- Aiming and accuracy
-- Enemy AI patterns
-- Level/arena design
-- Multiplayer considerations
-
----
-
-#### Fighting
-
-**Tags:** fighting, combat, competitive, combos, pvp
-
-1v1 combat with combos and frame data. Traditional fighters and platform fighters.
-
-**GDD sections added:**
-
-- Frame data systems
-- Combo mechanics
-- Character movesets
-- Competitive balance
-- Netcode requirements
-
----
-
-### Strategy & Tactics
-
-#### Strategy
-
-**Tags:** strategy, tactics, resources, planning
-
-Resource management with tactical decisions. RTS, 4X, and grand strategy.
-
-**GDD sections added:**
-
-- Resource systems
-- Unit/building design
-- AI opponent behavior
-- Map/scenario design
-- Victory conditions
-
----
-
-#### Turn-Based Tactics
-
-**Tags:** tactics, turn-based, grid, positioning
-
-Grid-based movement with turn order. XCOM-likes and tactical RPGs.
-
-**GDD sections added:**
-
-- Grid and movement systems
-- Turn order mechanics
-- Cover and positioning
-- Unit progression
-- Procedural mission generation
-
----
-
-#### Tower Defense
-
-**Tags:** tower-defense, waves, placement, strategy
-
-Wave-based defense with tower placement.
-
-**GDD sections added:**
-
-- Tower types and upgrades
-- Wave design and pacing
-- Economy systems
-- Map design patterns
-- Meta-progression
-
----
-
-### RPG & Progression
-
-#### RPG
-
-**Tags:** rpg, stats, inventory, quests, narrative
-
-Character progression with stats, inventory, and quests.
-
-**GDD sections added:**
-
-- Character stats and leveling
-- Inventory and equipment
-- Quest system design
-- Combat system (action/turn-based)
-- Skill trees and builds
-
----
-
-#### Roguelike
-
-**Tags:** roguelike, procedural, permadeath, runs
-
-Procedural generation with permadeath and run-based progression.
-
-**GDD sections added:**
-
-- Procedural generation rules
-- Permadeath and persistence
-- Run structure and pacing
-- Item/ability synergies
-- Meta-progression systems
-
----
-
-#### Metroidvania
-
-**Tags:** metroidvania, exploration, abilities, interconnected
-
-Interconnected world with ability gating.
-
-**GDD sections added:**
-
-- World map connectivity
-- Ability gating design
-- Backtracking flow
-- Secret and collectible placement
-- Power-up progression
-
----
-
-### Narrative & Story
-
-#### Adventure
-
-**Tags:** adventure, narrative, exploration, story
-
-Story-driven exploration and narrative. Point-and-click and narrative adventures.
-
-**GDD sections added:**
-
-- Puzzle design
-- Narrative delivery
-- Exploration mechanics
-- Dialogue systems
-- Story branching
-
----
-
-#### Visual Novel
-
-**Tags:** visual-novel, narrative, choices, story
-
-Narrative choices with branching story.
-
-**GDD sections added:**
-
-- Branching narrative structure
-- Choice and consequence
-- Character routes
-- UI/presentation
-- Save/load states
-
----
-
-#### Text-Based
-
-**Tags:** text, parser, interactive-fiction, mud
-
-Text input/output games. Parser games, choice-based IF, MUDs.
-
-**GDD sections added:**
-
-- Parser or choice systems
-- World model
-- Narrative structure
-- Text presentation
-- Save state management
-
----
-
-### Simulation & Management
-
-#### Simulation
-
-**Tags:** simulation, management, sandbox, systems
-
-Realistic systems with management and building. Includes tycoons and sim games.
-
-**GDD sections added:**
-
-- Core simulation loops
-- Economy modeling
-- AI agents/citizens
-- Building/construction
-- Failure states
-
----
-
-#### Sandbox
-
-**Tags:** sandbox, creative, building, freedom
-
-Creative freedom with building and minimal objectives.
-
-**GDD sections added:**
-
-- Creation tools
-- Physics/interaction systems
-- Persistence and saving
-- Sharing/community features
-- Optional objectives
-
----
-
-### Sports & Racing
-
-#### Racing
-
-**Tags:** racing, vehicles, tracks, speed
-
-Vehicle control with tracks and lap times.
-
-**GDD sections added:**
-
-- Vehicle physics model
-- Track design
-- AI opponents
-- Progression/career mode
-- Multiplayer racing
-
----
-
-#### Sports
-
-**Tags:** sports, teams, realistic, physics
-
-Team-based or individual sports simulation.
-
-**GDD sections added:**
-
-- Sport-specific rules
-- Player/team management
-- AI opponent behavior
-- Season/career modes
-- Multiplayer modes
-
----
-
-### Multiplayer
-
-#### MOBA
-
-**Tags:** moba, multiplayer, pvp, heroes, lanes
-
-Multiplayer team battles with hero selection.
-
-**GDD sections added:**
-
-- Hero/champion design
-- Lane and map design
-- Team composition
-- Matchmaking
-- Economy (gold/items)
-
----
-
-#### Party Game
-
-**Tags:** party, multiplayer, minigames, casual
-
-Local multiplayer with minigames.
-
-**GDD sections added:**
-
-- Minigame design patterns
-- Controller support
-- Round/game structure
-- Scoring systems
-- Player count flexibility
-
----
-
-### Horror & Survival
-
-#### Survival
-
-**Tags:** survival, crafting, resources, danger
-
-Resource gathering with crafting and persistent threats.
-
-**GDD sections added:**
-
-- Resource gathering
-- Crafting systems
-- Hunger/health/needs
-- Threat systems
-- Base building
-
----
-
-#### Horror
-
-**Tags:** horror, atmosphere, tension, fear
-
-Atmosphere and tension with limited resources.
-
-**GDD sections added:**
-
-- Fear mechanics
-- Resource scarcity
-- Sound design
-- Lighting and visibility
-- Enemy/threat design
-
----
-
-### Casual & Progression
-
-#### Puzzle
-
-**Tags:** puzzle, logic, cerebral
-
-Logic-based challenges and problem-solving.
-
-**GDD sections added:**
-
-- Puzzle mechanics
-- Difficulty progression
-- Hint systems
-- Level structure
-- Scoring/rating
-
----
-
-#### Idle/Incremental
-
-**Tags:** idle, incremental, automation, progression
-
-Passive progression with upgrades and automation.
-
-**GDD sections added:**
-
-- Core loop design
-- Prestige systems
-- Automation unlocks
-- Number scaling
-- Offline progress
-
----
-
-#### Card Game
-
-**Tags:** card, deck-building, strategy, turns
-
-Deck building with card mechanics.
-
-**GDD sections added:**
-
-- Card design framework
-- Deck building rules
-- Mana/resource systems
-- Rarity and collection
-- Competitive balance
-
----
-
-### Rhythm
-
-#### Rhythm
-
-**Tags:** rhythm, music, timing, beats
-
-Music synchronization with timing-based gameplay.
-
-**GDD sections added:**
-
-- Note/beat mapping
-- Scoring systems
-- Difficulty levels
-- Music licensing
-- Input methods
-
----
-
-## Hybrid Game Types
-
-Many games combine multiple genres. BMGD supports hybrid selection:
-
-### Examples
-
-**Action RPG** = Action Platformer + RPG
-
-- Movement and combat systems from Action Platformer
-- Progression and stats from RPG
-
-**Survival Horror** = Survival + Horror
-
-- Resource and crafting from Survival
-- Atmosphere and fear from Horror
-
-**Roguelike Deckbuilder** = Roguelike + Card Game
-
-- Run structure from Roguelike
-- Card mechanics from Card Game
-
-### How to Use Hybrids
-
-During GDD creation, select multiple game types when prompted:
-
-```
-Agent: What game type best describes your game?
-You: It's a roguelike with card game combat
-Agent: I'll include sections for both Roguelike and Card Game...
-```
-
----
-
-## Game Type Selection Tips
-
-### 1. Start with Core Fantasy
-
-What does the player primarily DO in your game?
-
-- Run and jump? → Platformer types
-- Build and manage? → Simulation types
-- Fight enemies? → Combat types
-- Make choices? → Narrative types
-
-### 2. Consider Your Loop
-
-What's the core gameplay loop?
-
-- Session-based runs? → Roguelike
-- Long-term progression? → RPG
-- Quick matches? → Multiplayer types
-- Creative expression? → Sandbox
-
-### 3. Don't Over-Combine
-
-2-3 game types maximum. More than that usually means your design isn't focused enough.
-
-### 4. Primary vs Secondary
-
-One type should be primary (most gameplay time). Others add flavor:
-
-- **Primary:** Platformer (core movement and exploration)
-- **Secondary:** Metroidvania (ability gating structure)
-
----
-
-## GDD Section Mapping
-
-When you select a game type, BMGD adds these GDD sections:
-
-| Game Type         | Key Sections Added                     |
-| ----------------- | -------------------------------------- |
-| Action Platformer | Movement, Combat, Level Design         |
-| RPG               | Stats, Inventory, Quests               |
-| Roguelike         | Procedural Gen, Runs, Meta-Progression |
-| Narrative         | Story Structure, Dialogue, Branching   |
-| Multiplayer       | Matchmaking, Netcode, Balance          |
-| Simulation        | Systems, Economy, AI                   |
-
----
-
-## Next Steps
-
-- **[Quick Start Guide](/docs/tutorials/getting-started/quick-start-bmgd.md)** - Get started with BMGD
-- **[Workflows Guide](/docs/reference/workflows/bmgd-workflows.md)** - GDD workflow details
-- **[Glossary](/docs/reference/glossary/index.md)** - Game development terminology

docs/explanation/game-dev/index.md

@@ -1,85 +0,0 @@
----
-title: "BMGD - Game Development Module"
-description: AI-powered workflows for game design and development with BMGD
----
-
-
-Complete guides for the BMad Game Development Module (BMGD) - AI-powered workflows for game design and development that adapt to your project's needs.
-
----
-
-## Getting Started
-
-**New to BMGD?** Start here:
-
-- **[Quick Start Guide](/docs/tutorials/getting-started/quick-start-bmgd.md)** - Get started building your first game
-  - Installation and setup
-  - Understanding the game development phases
-  - Running your first workflows
-  - Agent-based development flow
-
-**Quick Path:** Install BMGD module → Game Brief → GDD → Architecture → Build
-
----
-
-## Core Documentation
-
-- **[Game Types Guide](/docs/explanation/game-dev/game-types.md)** - Selecting and using game type templates (24 supported types)
-- **[BMGD vs BMM](/docs/explanation/game-dev/bmgd-vs-bmm.md)** - Understanding the differences
-
----
-
-## Game Development Phases
-
-BMGD follows four phases aligned with game development:
-
-### Phase 1: Preproduction
-- **Brainstorm Game** - Ideation with game-specific techniques
-- **Game Brief** - Capture vision, market, and fundamentals
-
-### Phase 2: Design
-- **GDD (Game Design Document)** - Comprehensive game design
-- **Narrative Design** - Story, characters, world (for story-driven games)
-
-### Phase 3: Technical
-- **Game Architecture** - Engine, systems, patterns, structure
-
-### Phase 4: Production
-- **Sprint Planning** - Epic and story management
-- **Story Development** - Implementation workflow
-- **Code Review** - Quality assurance
-- **Testing** - Automated tests, playtesting, performance
-- **Retrospective** - Continuous improvement
-
----
-
-## Choose Your Path
-
-### I need to...
-
-**Start a new game project**
-→ Start with [Quick Start Guide](/docs/tutorials/getting-started/quick-start-bmgd.md)
-→ Run `brainstorm-game` for ideation
-→ Create a Game Brief with `create-brief`
-
-**Design my game**
-→ Create a GDD with `create-gdd`
-→ If story-heavy, add Narrative Design with `create-narrative`
-
-**Plan the technical architecture**
-→ Run `create-architecture` with the Game Architect
-
-**Build my game**
-→ Use Phase 4 production workflows
-→ Follow the sprint-based development cycle
-
-**Quickly test an idea**
-→ Use [Quick-Flow](/docs/how-to/workflows/bmgd-quick-flow.md) for rapid prototyping
-
----
-
-## Related
-
-- [Game Types Guide](/docs/explanation/game-dev/game-types.md) - Understanding game type templates
-- [BMGD vs BMM](/docs/explanation/game-dev/bmgd-vs-bmm.md) - Comparison with core method
-- [Glossary](/docs/reference/glossary/index.md) - Terminology reference

docs/explanation/philosophy/facilitation-over-generation.md

@@ -1,121 +1,333 @@
 ---
 title: "Facilitation Over Generation"
-description: Understanding CIS's facilitation-first approach to creative work
+description: Understanding a facilitation-first approach to AI workflows and creative collaboration
 ---
 
+BMAD workflows take a fundamentally different approach from typical AI Prompts you will find. Instead of generating solutions directly, workflows act as facilitators who guide you through discovery processes, helping you arrive at insights and decisions yourself.
 
-The Creative Intelligence Suite (CIS) takes a fundamentally different approach from typical AI tools. Instead of generating solutions directly, CIS agents act as master facilitators who guide you to discover insights yourself.
-
----
+This has always been the magic of the BMad method - if you have used it you have felt it intuitively and noticed a difference - and it is through this document I want to really explain what this is. This is fundamental to understand if you are also interested in producing your own workflows or improving upon existing ones in any BMad related module.
 
 ## The Problem with Generation
 
-Traditional AI approaches to creative work:
+Traditional AI approaches to creative and knowledge work typically follow this pattern:
 
-```
-User: "Give me marketing ideas"
-AI: "Here are 10 marketing ideas..."
-```
+:::note[Generation Example]
+**User:** "I need a comprehensive UX design for my e-commerce app"
+
+**AI:** [Immediately generates] "Here's a complete UX specification with modern dark theme, card-based product grid, left navigation, and checkout flow..."
+:::
 
 This approach:
-- Produces generic, predictable outputs
-- Removes human ownership of ideas
-- Misses context and nuance
-- Limits creative exploration
-
----
+- Produces generic, predictable outputs that may not fit your actual needs
+- Removes your ownership and understanding of the solution
+- Misses critical context, constraints, and nuance
+- Limits creative exploration to the AI's training data patterns
+- Creates deliverables you can't explain or iterate on effectively
 
 ## The Facilitation Approach
 
-CIS agents use strategic questioning:
+Facilitative workflows use strategic questioning and guided discovery:
 
-```
-User: "I need marketing ideas"
-CIS: "What makes your customers choose you over alternatives?
-      What's the one thing they always mention?"
-User: "They say our support is exceptional"
-CIS: "Interesting! How might you make that exceptional
-      support visible before they become customers?"
-```
+:::note[Facilitation Example from UX Design Workflow]
+**User:** "I need a comprehensive UX design for my e-commerce app"
+
+**Workflow:** "Welcome! I'll act as your UX facilitator to help you discover the right approach. First, let me understand what documents you already have—do you have a product brief, PRD, or any research?"
+
+**User:** "I have a product brief and some user research"
+
+**Workflow:** "Great! Let me load those. [Loads documents] Now, what are the primary user goals for your e-commerce experience? What should users be able to accomplish?"
+
+**User:** "They need to browse products quickly and complete purchases without friction"
+
+**Workflow:** "Interesting! And what makes your e-commerce situation unique? What are the specific challenges or constraints you're working with?"
+:::
 
 This approach:
-- Draws out insights already within you
-- Maintains human ownership of ideas
-- Captures context and nuance
-- Enables deeper creative exploration
+- Draws out insights and expertise already within you
+- Maintains your ownership and understanding of decisions
+- Captures your specific context, constraints, and goals
+- Enables deeper exploration of your unique situation
+- Creates outputs you can confidently explain and iterate on
 
----
+## Real-World Examples from BMAD Workflows
+
+### Brainstorming Workflow (from core module)
+
+The brainstorming workflow demonstrates pure facilitation through its entire journey:
+
+**Session Setup:**
+```
+"Welcome! I'm excited to facilitate your brainstorming session. I'll guide you
+through proven creativity techniques to generate innovative ideas.
+
+**What are we brainstorming about?** (The central topic or challenge)
+**What specific outcomes are you hoping for?** (Types of ideas, solutions, or insights)
+```
+
+**Technique Selection - Offering Options:**
+```
+"Ready to explore technique approaches?
+[1] User-Selected Techniques - Browse our complete technique library
+[2] AI-Recommended Techniques - Get customized suggestions based on your goals
+[3] Random Technique Selection - Discover unexpected creative methods
+[4] Progressive Technique Flow - Start broad, then systematically narrow focus
+
+Which approach appeals to you most?"
+```
+
+**Technique Execution - Interactive Coaching:**
+The workflow doesn't generate ideas—it coaches you through techniques with genuine back-and-forth dialogue:
+
+```
+"Let's start with: What if you could remove all practical constraints?
+
+I'm not just looking for a quick answer - I want to explore this together.
+What immediately comes to mind? Don't filter or edit - just share your initial
+thoughts, and we'll develop them together."
+
+[User responds]
+
+"That's interesting! Tell me more about [specific aspect you mentioned].
+What would that look like in practice? How does that connect to your core goal?"
+```
+
+**Key facilitation behaviors:**
+- Aims for 100+ ideas before suggesting organization
+- Asks "Continue exploring?" or "Move to next technique?"—user controls pace
+- Uses anti-bias protocols to force thinking in new directions every 10 ideas
+- Builds on user's ideas with genuine creative contributions
+- Keeps user in "generative exploration mode" as long as possible
+
+**Organization - Collaborative Synthesis:**
+```
+"Outstanding creative work! You've generated an incredible range of ideas.
+Now let's organize these creative gems and identify your most promising opportunities.
+
+I'm analyzing all your generated ideas to identify natural themes and patterns.
+**Emerging Themes I'm Identifying:**
+- Theme 1: [Name] - Ideas: [list] - Pattern: [connection]
+- Theme 2: [Name] - Ideas: [list] - Pattern: [connection]
+
+Which themes or specific ideas stand out to you as most valuable?"
+```
+
+Result: A comprehensive brainstorming session document with **your** ideas, organized by **your** priorities, with **your** action plans.
+
+### Create UX Design Workflow (from BMM method)
+
+The UX design workflow facilitates a 14-step journey from project understanding to complete UX specification—**never making design decisions for you**.
+
+**Step 1: Document Discovery (Collaborative Setup)**
+```
+"Welcome! I've set up your UX design workspace.
+
+**Documents Found:**
+- PRD: product-requirements.md
+- Product brief: brief.md
+
+**Files loaded:** [lists specific files]
+
+Do you have any other documents you'd like me to include, or shall we continue?"
+```
+
+**Step 2: Project Understanding (Discovery Questions)**
+```
+"Based on the project documentation, let me confirm what I'm understanding...
+
+**From the documents:** [summary of key insights]
+**Target Users:** [summary from documents]
+**Key Features/Goals:** [summary from documents]
+
+Does this match your understanding? Are there any corrections or additions?"
+```
+
+Then it dives deeper with targeted questions:
+```
+"Let me understand your users better to inform the UX design:
+
+**User Context Questions:**
+- What problem are users trying to solve?
+- What frustrates them with current solutions?
+- What would make them say 'this is exactly what I needed'?"
+```
+
+**Step 3: Core Experience Definition (Guiding Insights)**
+```
+"Now let's dig into the heart of the user experience.
+
+**Core Experience Questions:**
+- What's the ONE thing users will do most frequently?
+- What user action is absolutely critical to get right?
+- What should be completely effortless for users?
+- If we nail one interaction, everything else follows - what is it?
+
+Think about the core loop or primary action that defines your product's value."
+```
+
+**Step 4: Emotional Response (Feelings-Based Design)**
+```
+"Now let's think about how your product should make users feel.
+
+**Emotional Response Questions:**
+- What should users FEEL when using this product?
+- What emotion would make them tell a friend about this?
+- How should users feel after accomplishing their primary goal?
+
+Common emotional goals: Empowered and in control? Delighted and surprised?
+Efficient and productive? Creative and inspired?"
+```
+
+**Step 5: Pattern Inspiration (Learning from Examples)**
+```
+"Let's learn from products your users already love and use regularly.
+
+**Inspiration Questions:**
+- Name 2-3 apps your target users already love and USE frequently
+- For each one, what do they do well from a UX perspective?
+- What makes the experience compelling or delightful?
+
+For each inspiring app, let's analyze their UX success:
+- What core problem does it solve elegantly?
+- What makes the onboarding experience effective?
+- How do they handle navigation and information hierarchy?"
+```
+
+**Step 9: Design Directions (Interactive Visual Exploration)**
+The workflow generates 6-8 HTML mockup variations—but **you choose**:
+
+```
+"🎨 Design Direction Mockups Generated!
+
+I'm creating a comprehensive HTML showcase with 6-8 full-screen mockup variations.
+Each mockup represents a complete visual direction for your app's look and feel.
+
+**As you explore the design directions, look for:**
+✅ Which information hierarchy matches your priorities?
+✅ Which interaction style fits your core experience?
+✅ Which visual density feels right for your brand?
+
+**Which approach resonates most with you?**
+- Pick a favorite direction as-is
+- Combine elements from multiple directions
+- Request modifications to any direction
+
+Tell me: Which layout feels most intuitive? Which visual weight matches your brand?"
+```
+
+**Step 12: UX Patterns (Consistency Through Questions)**
+```
+"Let's establish consistency patterns for common situations.
+
+**Pattern Categories to Define:**
+- Button hierarchy and actions
+- Feedback patterns (success, error, warning, info)
+- Form patterns and validation
+- Navigation patterns
+
+Which categories are most critical for your product?
+
+**For [Critical Pattern Category]:**
+What should users see/do when they need to [pattern action]?
+
+**Considerations:**
+- Visual hierarchy (primary vs. secondary actions)
+- Feedback mechanisms
+- Error recovery
+- Accessibility requirements
+
+How should your product handle [pattern type] interactions?"
+```
+
+**The Result:** A complete, production-ready UX specification document that captures **your** decisions, **your** reasoning, and **your** vision—documented through guided discovery, not generation.
 
 ## Key Principles
 
 ### 1. Questions Over Answers
 
-CIS agents ask strategic questions rather than providing direct answers. This:
-- Activates your own creative thinking
-- Uncovers assumptions
-- Reveals blind spots
-- Builds on your domain knowledge
+Facilitative workflows ask strategic questions rather than providing direct answers. This:
+- Activates your own creative and analytical thinking
+- Uncovers assumptions you didn't know you had
+- Reveals blind spots in your understanding
+- Builds on your domain expertise and context
 
-### 2. Energy-Aware Sessions
+### 2. Multi-Turn Conversation
 
-CIS monitors engagement and adapts:
-- Adjusts pace when energy flags
-- Suggests breaks when needed
-- Changes techniques to maintain momentum
-- Recognizes productive vs. unproductive struggle
+Facilitation uses progressive discovery, not interrogation:
+- Ask 1-2 questions at a time, not laundry lists
+- Think about responses before asking follow-ups
+- Probe to understand deeper, not just collect facts
+- Use conversation to explore, not just extract
 
-### 3. Process Trust
+### 3. Intent-Based Guidance
 
-CIS uses proven methodologies:
-- Design Thinking's 5 phases
-- Structured brainstorming techniques
+Workflows specify goals and approaches, not exact scripts:
+- "Guide the user through discovering X" (intent)
+- NOT "Say exactly: 'What is X?'" (prescriptive)
+
+This allows the workflow to adapt naturally to your responses while maintaining structured progress.
+
+### 4. Process Trust
+
+Facilitative workflows use proven methodologies:
+- Design Thinking's phases (Empathize, Define, Ideate, Prototype, Test)
+- Structured brainstorming and creativity techniques
 - Root cause analysis frameworks
 - Innovation strategy patterns
 
-You're not just having a conversation—you're following time-tested creative processes.
+You're not just having a conversation—you're following time-tested processes adapted to your specific situation.
 
-### 4. Persona-Driven Engagement
+### 5. YOU Are the Expert
 
-Each CIS agent has a distinct personality:
-- **Carson** - Energetic, encouraging
-- **Maya** - Jazz-like, improvisational
-- **Dr. Quinn** - Analytical, methodical
-- **Victor** - Bold, strategic
-- **Sophia** - Narrative, imaginative
+Facilitative workflows operate on a core principle: **you are the expert on your situation**. The workflow brings:
+- Process expertise (how to think through problems)
+- Facilitation skills (how to guide exploration)
+- Technique knowledge (proven methods and frameworks)
 
-These personas create engaging experiences that maintain creative flow.
-
----
+You bring:
+- Domain knowledge (your specific field or industry)
+- Context understanding (your unique situation and constraints)
+- Decision authority (what will actually work for you)
 
 ## When Generation is Appropriate
 
-CIS does generate when appropriate:
-- Synthesizing session outputs
-- Documenting decisions
-- Creating structured artifacts
-- Providing technique examples
+Facilitative workflows DO generate when appropriate:
+- Synthesizing and structuring outputs after you've made decisions
+- Documenting your choices and rationale
+- Creating structured artifacts based on your input
+- Providing technique examples or option templates
+- Formatting and organizing your conclusions
 
-But the core creative work happens through facilitated discovery.
+But the **core creative and analytical work** happens through facilitated discovery, not generation.
 
----
+## The Distinction: Facilitator vs Generator
+
+| Facilitative Workflow                 | Generative AI                           |
+| ------------------------------------- | --------------------------------------- |
+| "What are your goals?"                | "Here's the solution"                   |
+| Asks 1-2 questions at a time          | Produces complete output immediately    |
+| Multiple turns, progressive discovery | Single turn, bulk generation            |
+| "Let me understand your context"      | "Here's a generic answer"               |
+| Offers options, you choose            | Makes decisions for you                 |
+| Documents YOUR reasoning              | No reasoning visible                    |
+| You can explain every decision        | You can't explain why choices were made |
+| Ownership and understanding           | Outputs feel alien                      |
 
 ## Benefits
 
 ### For Individuals
-- Deeper insights than pure generation
-- Ownership of creative outputs
-- Skill development in creative thinking
-- More memorable and actionable ideas
+- **Deeper insights** than pure generation—ideas connect to your actual knowledge
+- **Full ownership** of creative outputs and decisions
+- **Skill development** in structured thinking and problem-solving
+- **More memorable and actionable** results—you understand the "why"
 
 ### For Teams
-- Shared creative experience
-- Aligned understanding
-- Documented rationale
-- Stronger buy-in to outcomes
+- **Shared creative experience** building alignment and trust
+- **Aligned understanding** through documented exploration
+- **Documented rationale** for future reference and onboarding
+- **Stronger buy-in** to outcomes because everyone participated in discovery
 
----
-
-## Related
-
-- [Creative Intelligence Suite](/docs/explanation/creative-intelligence/index.md) - CIS overview
-- [Brainstorming Techniques](/docs/explanation/features/brainstorming-techniques.md) - Available techniques
+### For Implementation
+- **Outputs match reality** because they emerged from your actual constraints
+- **Easier iteration** because you understand the reasoning behind choices
+- **Confident implementation** because you can defend every decision
+- **Reduced rework** because facilitation catches issues early

docs/explanation/philosophy/testing-as-engineering.md

@@ -110,10 +110,3 @@ The three-part stack addresses each gap:
 | No review | TEA `*test-review` audits quality with scoring |
 
 This approach is sometimes called *context engineering*—loading domain-specific standards into AI context automatically rather than relying on prompts alone. TEA's `tea-index.csv` manifest loads relevant knowledge fragments so the AI doesn't relearn testing patterns each session.
-
-## Related
-
-- [TEA Overview](/docs/explanation/features/tea-overview.md) — Workflow details and cheat sheets
-- [Setup Test Framework](/docs/how-to/workflows/setup-test-framework.md) — Implementation guide
-- [The Testing Meta Most Teams Have Not Caught Up To Yet](https://dev.to/muratkeremozcan/the-testing-meta-most-teams-have-not-caught-up-to-yet-5765) — Original article by Murat K Ozcan
-- [Playwright-Utils Repository](https://github.com/seontechnologies/playwright-utils) — Source and documentation

docs/explanation/tea/engagement-models.md

@@ -0,0 +1,710 @@
+---
+title: "TEA Engagement Models Explained"
+description: Understanding the five ways to use TEA - from standalone to full BMad Method integration
+---
+
+# TEA Engagement Models Explained
+
+TEA is optional and flexible. There are five valid ways to engage with TEA - choose intentionally based on your project needs and methodology.
+
+## Overview
+
+**TEA is not mandatory.** Pick the engagement model that fits your context:
+
+1. **No TEA** - Skip all TEA workflows, use existing testing approach
+2. **TEA Solo** - Use TEA standalone without BMad Method
+3. **TEA Lite** - Beginner approach using just `*automate`
+4. **TEA Integrated (Greenfield)** - Full BMad Method integration from scratch
+5. **TEA Integrated (Brownfield)** - Full BMad Method integration with existing code
+
+## The Problem
+
+### One-Size-Fits-All Doesn't Work
+
+**Traditional testing tools force one approach:**
+- Must use entire framework
+- All-or-nothing adoption
+- No flexibility for different project types
+- Teams abandon tool if it doesn't fit
+
+**TEA recognizes:**
+- Different projects have different needs
+- Different teams have different maturity levels
+- Different contexts require different approaches
+- Flexibility increases adoption
+
+## The Five Engagement Models
+
+### Model 1: No TEA
+
+**What:** Skip all TEA workflows, use your existing testing approach.
+
+**When to Use:**
+- Team has established testing practices
+- Quality is already high
+- Testing tools already in place
+- TEA doesn't add value
+
+**What You Miss:**
+- Risk-based test planning
+- Systematic quality review
+- Gate decisions with evidence
+- Knowledge base patterns
+
+**What You Keep:**
+- Full control
+- Existing tools
+- Team expertise
+- No learning curve
+
+**Example:**
+```
+Your team:
+- 10-year veteran QA team
+- Established testing practices
+- High-quality test suite
+- No problems to solve
+
+Decision: Skip TEA, keep what works
+```
+
+**Verdict:** Valid choice if existing approach works.
+
+---
+
+### Model 2: TEA Solo
+
+**What:** Use TEA workflows standalone without full BMad Method integration.
+
+**When to Use:**
+- Non-BMad projects
+- Want TEA's quality operating model only
+- Don't need full planning workflow
+- Bring your own requirements
+
+**Typical Sequence:**
+```
+1. *test-design (system or epic)
+2. *atdd or *automate
+3. *test-review (optional)
+4. *trace (coverage + gate decision)
+```
+
+**You Bring:**
+- Requirements (user stories, acceptance criteria)
+- Development environment
+- Project context
+
+**TEA Provides:**
+- Risk-based test planning (`*test-design`)
+- Test generation (`*atdd`, `*automate`)
+- Quality review (`*test-review`)
+- Coverage traceability (`*trace`)
+
+**Optional:**
+- Framework setup (`*framework`) if needed
+- CI configuration (`*ci`) if needed
+
+**Example:**
+```
+Your project:
+- Using Scrum (not BMad Method)
+- Jira for story management
+- Need better test strategy
+
+Workflow:
+1. Export stories from Jira
+2. Run *test-design on epic
+3. Run *atdd for each story
+4. Implement features
+5. Run *trace for coverage
+```
+
+**Verdict:** Best for teams wanting TEA benefits without BMad Method commitment.
+
+---
+
+### Model 3: TEA Lite
+
+**What:** Beginner approach using just `*automate` to test existing features.
+
+**When to Use:**
+- Learning TEA fundamentals
+- Want quick results
+- Testing existing application
+- No time for full methodology
+
+**Workflow:**
+```
+1. *framework (setup test infrastructure)
+2. *test-design (optional, risk assessment)
+3. *automate (generate tests for existing features)
+4. Run tests (they pass immediately)
+```
+
+**Example:**
+```
+Beginner developer:
+- Never used TEA before
+- Want to add tests to existing app
+- 30 minutes available
+
+Steps:
+1. Run *framework
+2. Run *automate on TodoMVC demo
+3. Tests generated and passing
+4. Learn TEA basics
+```
+
+**What You Get:**
+- Working test framework
+- Passing tests for existing features
+- Learning experience
+- Foundation to expand
+
+**What You Miss:**
+- TDD workflow (ATDD)
+- Risk-based planning (test-design depth)
+- Quality gates (trace Phase 2)
+- Full TEA capabilities
+
+**Verdict:** Perfect entry point for beginners.
+
+---
+
+### Model 4: TEA Integrated (Greenfield)
+
+**What:** Full BMad Method integration with TEA workflows across all phases.
+
+**When to Use:**
+- New projects starting from scratch
+- Using BMad Method or Enterprise track
+- Want complete quality operating model
+- Testing is critical to success
+
+**Lifecycle:**
+
+**Phase 2: Planning**
+- PM creates PRD with NFRs
+- (Optional) TEA runs `*nfr-assess` (Enterprise only)
+
+**Phase 3: Solutioning**
+- Architect creates architecture
+- TEA runs `*test-design` (system-level) → testability review
+- TEA runs `*framework` → test infrastructure
+- TEA runs `*ci` → CI/CD pipeline
+- Architect runs `*implementation-readiness` (fed by test design)
+
+**Phase 4: Implementation (Per Epic)**
+- SM runs `*sprint-planning`
+- TEA runs `*test-design` (epic-level) → risk assessment for THIS epic
+- SM creates stories
+- (Optional) TEA runs `*atdd` → failing tests before dev
+- DEV implements story
+- TEA runs `*automate` → expand coverage
+- (Optional) TEA runs `*test-review` → quality audit
+- TEA runs `*trace` Phase 1 → refresh coverage
+
+**Release Gate:**
+- (Optional) TEA runs `*test-review` → final audit
+- (Optional) TEA runs `*nfr-assess` → validate NFRs
+- TEA runs `*trace` Phase 2 → gate decision (PASS/CONCERNS/FAIL/WAIVED)
+
+**What You Get:**
+- Complete quality operating model
+- Systematic test planning
+- Risk-based prioritization
+- Evidence-based gate decisions
+- Consistent patterns across epics
+
+**Example:**
+```
+New SaaS product:
+- 50 stories across 8 epics
+- Security critical
+- Need quality gates
+
+Workflow:
+- Phase 2: Define NFRs in PRD
+- Phase 3: Architecture → test design → framework → CI
+- Phase 4: Per epic: test design → ATDD → dev → automate → review → trace
+- Gate: NFR assess → trace Phase 2 → decision
+```
+
+**Verdict:** Most comprehensive TEA usage, best for structured teams.
+
+---
+
+### Model 5: TEA Integrated (Brownfield)
+
+**What:** Full BMad Method integration with TEA for existing codebases.
+
+**When to Use:**
+- Existing codebase with legacy tests
+- Want to improve test quality incrementally
+- Adding features to existing application
+- Need to establish coverage baseline
+
+**Differences from Greenfield:**
+
+**Phase 0: Documentation (if needed)**
+```
+- Run *document-project
+- Create baseline documentation
+```
+
+**Phase 2: Planning**
+```
+- TEA runs *trace Phase 1 → establish coverage baseline
+- PM creates PRD (with existing system context)
+```
+
+**Phase 3: Solutioning**
+```
+- Architect creates architecture (with brownfield constraints)
+- TEA runs *test-design (system-level) → testability review
+- TEA runs *framework (only if modernizing test infra)
+- TEA runs *ci (update existing CI or create new)
+```
+
+**Phase 4: Implementation**
+```
+- TEA runs *test-design (epic-level) → focus on REGRESSION HOTSPOTS
+- Per story: ATDD → dev → automate
+- TEA runs *test-review → improve legacy test quality
+- TEA runs *trace Phase 1 → track coverage improvement
+```
+
+**Brownfield-Specific:**
+- Baseline coverage BEFORE planning
+- Focus on regression hotspots (bug-prone areas)
+- Incremental quality improvement
+- Compare coverage to baseline (trending up?)
+
+**Example:**
+```
+Legacy e-commerce platform:
+- 200 existing tests (30% passing, 70% flaky)
+- Adding new checkout flow
+- Want to improve quality
+
+Workflow:
+1. Phase 2: *trace baseline → 30% coverage
+2. Phase 3: *test-design → identify regression risks
+3. Phase 4: Fix top 20 flaky tests + add tests for new checkout
+4. Gate: *trace → 60% coverage (2x improvement)
+```
+
+**Verdict:** Best for incrementally improving legacy systems.
+
+---
+
+## Decision Guide: Which Model?
+
+### Quick Decision Tree
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': { 'fontSize':'14px'}}}%%
+flowchart TD
+    Start([Choose TEA Model]) --> BMad{Using<br/>BMad Method?}
+
+    BMad -->|No| NonBMad{Project Type?}
+    NonBMad -->|Learning| Lite[TEA Lite<br/>Just *automate<br/>30 min tutorial]
+    NonBMad -->|Serious Project| Solo[TEA Solo<br/>Standalone workflows<br/>Full capabilities]
+
+    BMad -->|Yes| WantTEA{Want TEA?}
+    WantTEA -->|No| None[No TEA<br/>Use existing approach<br/>Valid choice]
+    WantTEA -->|Yes| ProjectType{New or<br/>Existing?}
+
+    ProjectType -->|New Project| Green[TEA Integrated<br/>Greenfield<br/>Full lifecycle]
+    ProjectType -->|Existing Code| Brown[TEA Integrated<br/>Brownfield<br/>Baseline + improve]
+
+    Green --> Compliance{Compliance<br/>Needs?}
+    Compliance -->|Yes| Enterprise[Enterprise Track<br/>NFR + audit trails]
+    Compliance -->|No| Method[BMad Method Track<br/>Standard quality]
+
+    style Lite fill:#bbdefb,stroke:#1565c0,stroke-width:2px
+    style Solo fill:#c5cae9,stroke:#283593,stroke-width:2px
+    style None fill:#e0e0e0,stroke:#616161,stroke-width:1px
+    style Green fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
+    style Brown fill:#fff9c4,stroke:#f57f17,stroke-width:2px
+    style Enterprise fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px
+    style Method fill:#e1f5fe,stroke:#01579b,stroke-width:2px
+```
+
+**Decision Path Examples:**
+- Learning TEA → TEA Lite (blue)
+- Non-BMad project → TEA Solo (purple)
+- BMad + new project + compliance → Enterprise (purple)
+- BMad + existing code → Brownfield (yellow)
+- Don't want TEA → No TEA (gray)
+
+### By Project Type
+
+| Project Type | Recommended Model | Why |
+|--------------|------------------|-----|
+| **New SaaS product** | TEA Integrated (Greenfield) | Full quality operating model from day one |
+| **Existing app + new feature** | TEA Integrated (Brownfield) | Improve incrementally while adding features |
+| **Bug fix** | TEA Lite or No TEA | Quick flow, minimal overhead |
+| **Learning project** | TEA Lite | Learn basics with immediate results |
+| **Non-BMad enterprise** | TEA Solo | Quality model without full methodology |
+| **High-quality existing tests** | No TEA | Keep what works |
+
+### By Team Maturity
+
+| Team Maturity | Recommended Model | Why |
+|---------------|------------------|-----|
+| **Beginners** | TEA Lite → TEA Solo | Learn basics, then expand |
+| **Intermediate** | TEA Solo or Integrated | Depends on methodology |
+| **Advanced** | TEA Integrated or No TEA | Full model or existing expertise |
+
+### By Compliance Needs
+
+| Compliance | Recommended Model | Why |
+|------------|------------------|-----|
+| **None** | Any model | Choose based on project needs |
+| **Light** (internal audit) | TEA Solo or Integrated | Gate decisions helpful |
+| **Heavy** (SOC 2, HIPAA) | TEA Integrated (Enterprise) | NFR assessment mandatory |
+
+## Switching Between Models
+
+### Can Change Models Mid-Project
+
+**Scenario:** Start with TEA Lite, expand to TEA Solo
+
+```
+Week 1: TEA Lite
+- Run *framework
+- Run *automate
+- Learn basics
+
+Week 2: Expand to TEA Solo
+- Add *test-design
+- Use *atdd for new features
+- Add *test-review
+
+Week 3: Continue expanding
+- Add *trace for coverage
+- Setup *ci
+- Full TEA Solo workflow
+```
+
+**Benefit:** Start small, expand as comfortable.
+
+### Can Mix Models
+
+**Scenario:** TEA Integrated for main features, No TEA for bug fixes
+
+```
+Main features (epics):
+- Use full TEA workflow
+- Risk assessment, ATDD, quality gates
+
+Bug fixes:
+- Skip TEA
+- Quick Flow + manual testing
+- Move fast
+
+Result: TEA where it adds value, skip where it doesn't
+```
+
+**Benefit:** Flexible, pragmatic, not dogmatic.
+
+## Comparison Table
+
+| Aspect | No TEA | TEA Lite | TEA Solo | Integrated (Green) | Integrated (Brown) |
+|--------|--------|----------|----------|-------------------|-------------------|
+| **BMad Required** | No | No | No | Yes | Yes |
+| **Learning Curve** | None | Low | Medium | High | High |
+| **Setup Time** | 0 | 30 min | 2 hours | 1 day | 2 days |
+| **Workflows Used** | 0 | 2-3 | 4-6 | 8 | 8 |
+| **Test Planning** | Manual | Optional | Yes | Systematic | + Regression focus |
+| **Quality Gates** | No | No | Optional | Yes | Yes + baseline |
+| **NFR Assessment** | No | No | No | Optional | Recommended |
+| **Coverage Tracking** | Manual | No | Optional | Yes | Yes + trending |
+| **Best For** | Experts | Beginners | Standalone | New projects | Legacy code |
+
+## Real-World Examples
+
+### Example 1: Startup (TEA Lite → TEA Integrated)
+
+**Month 1:** TEA Lite
+```
+Team: 3 developers, no QA
+Testing: Manual only
+Decision: Start with TEA Lite
+
+Result:
+- Run *framework (Playwright setup)
+- Run *automate (20 tests generated)
+- Learning TEA basics
+```
+
+**Month 3:** TEA Solo
+```
+Team: Growing to 5 developers
+Testing: Automated tests exist
+Decision: Expand to TEA Solo
+
+Result:
+- Add *test-design (risk assessment)
+- Add *atdd (TDD workflow)
+- Add *test-review (quality audits)
+```
+
+**Month 6:** TEA Integrated
+```
+Team: 8 developers, 1 QA
+Testing: Critical to business
+Decision: Full BMad Method + TEA Integrated
+
+Result:
+- Full lifecycle integration
+- Quality gates before releases
+- NFR assessment for enterprise customers
+```
+
+### Example 2: Enterprise (TEA Integrated - Brownfield)
+
+**Project:** Legacy banking application
+
+**Challenge:**
+- 500 existing tests (50% flaky)
+- Adding new features
+- SOC 2 compliance required
+
+**Model:** TEA Integrated (Brownfield)
+
+**Phase 2:**
+```
+- *trace baseline → 45% coverage (lots of gaps)
+- Document current state
+```
+
+**Phase 3:**
+```
+- *test-design (system) → identify regression hotspots
+- *framework → modernize test infrastructure
+- *ci → add selective testing
+```
+
+**Phase 4:**
+```
+Per epic:
+- *test-design → focus on regression + new features
+- Fix top 10 flaky tests
+- *atdd for new features
+- *automate for coverage expansion
+- *test-review → track quality improvement
+- *trace → compare to baseline
+```
+
+**Result after 6 months:**
+- Coverage: 45% → 85%
+- Quality score: 52 → 82
+- Flakiness: 50% → 2%
+- SOC 2 compliant (traceability + NFR evidence)
+
+### Example 3: Consultancy (TEA Solo)
+
+**Context:** Testing consultancy working with multiple clients
+
+**Challenge:**
+- Different clients use different methodologies
+- Need consistent testing approach
+- Not always using BMad Method
+
+**Model:** TEA Solo (bring to any client project)
+
+**Workflow:**
+```
+Client project 1 (Scrum):
+- Import Jira stories
+- Run *test-design
+- Generate tests with *atdd/*automate
+- Deliver quality report with *test-review
+
+Client project 2 (Kanban):
+- Import requirements from Notion
+- Same TEA workflow
+- Consistent quality across clients
+
+Client project 3 (Ad-hoc):
+- Document requirements manually
+- Same TEA workflow
+- Same patterns, different context
+```
+
+**Benefit:** Consistent testing approach regardless of client methodology.
+
+## Choosing Your Model
+
+### Start Here Questions
+
+**Question 1:** Are you using BMad Method?
+- **No** → TEA Solo or TEA Lite or No TEA
+- **Yes** → TEA Integrated or No TEA
+
+**Question 2:** Is this a new project?
+- **Yes** → TEA Integrated (Greenfield) or TEA Lite
+- **No** → TEA Integrated (Brownfield) or TEA Solo
+
+**Question 3:** What's your testing maturity?
+- **Beginner** → TEA Lite
+- **Intermediate** → TEA Solo or Integrated
+- **Advanced** → TEA Integrated or No TEA (already expert)
+
+**Question 4:** Do you need compliance/quality gates?
+- **Yes** → TEA Integrated (Enterprise)
+- **No** → Any model
+
+**Question 5:** How much time can you invest?
+- **30 minutes** → TEA Lite
+- **Few hours** → TEA Solo
+- **Multiple days** → TEA Integrated
+
+### Recommendation Matrix
+
+| Your Context | Recommended Model | Alternative |
+|--------------|------------------|-------------|
+| BMad Method + new project | TEA Integrated (Greenfield) | TEA Lite (learning) |
+| BMad Method + existing code | TEA Integrated (Brownfield) | TEA Solo |
+| Non-BMad + need quality | TEA Solo | TEA Lite |
+| Just learning testing | TEA Lite | No TEA (learn basics first) |
+| Enterprise + compliance | TEA Integrated (Enterprise) | TEA Solo |
+| Established QA team | No TEA | TEA Solo (supplement) |
+
+## Transitioning Between Models
+
+### TEA Lite → TEA Solo
+
+**When:** Outgrow beginner approach, need more workflows.
+
+**Steps:**
+1. Continue using `*framework` and `*automate`
+2. Add `*test-design` for planning
+3. Add `*atdd` for TDD workflow
+4. Add `*test-review` for quality audits
+5. Add `*trace` for coverage tracking
+
+**Timeline:** 2-4 weeks of gradual expansion
+
+### TEA Solo → TEA Integrated
+
+**When:** Adopt BMad Method, want full integration.
+
+**Steps:**
+1. Install BMad Method (see installation guide)
+2. Run planning workflows (PRD, architecture)
+3. Integrate TEA into Phase 3 (system-level test design)
+4. Follow integrated lifecycle (per epic workflows)
+5. Add release gates (trace Phase 2)
+
+**Timeline:** 1-2 sprints of transition
+
+### TEA Integrated → TEA Solo
+
+**When:** Moving away from BMad Method, keep TEA.
+
+**Steps:**
+1. Export BMad artifacts (PRD, architecture, stories)
+2. Continue using TEA workflows standalone
+3. Skip BMad-specific integration
+4. Bring your own requirements to TEA
+
+**Timeline:** Immediate (just skip BMad workflows)
+
+## Common Patterns
+
+### Pattern 1: TEA Lite for Learning, Then Choose
+
+```
+Phase 1 (Week 1-2): TEA Lite
+- Learn with *automate on demo app
+- Understand TEA fundamentals
+- Low commitment
+
+Phase 2 (Week 3-4): Evaluate
+- Try *test-design (planning)
+- Try *atdd (TDD)
+- See if value justifies investment
+
+Phase 3 (Month 2+): Decide
+- Valuable → Expand to TEA Solo or Integrated
+- Not valuable → Stay with TEA Lite or No TEA
+```
+
+### Pattern 2: TEA Solo for Quality, Skip Full Method
+
+```
+Team decision:
+- Don't want full BMad Method (too heavyweight)
+- Want systematic testing (TEA benefits)
+
+Approach: TEA Solo only
+- Use existing project management (Jira, Linear)
+- Use TEA for testing only
+- Get quality without methodology commitment
+```
+
+### Pattern 3: Integrated for Critical, Lite for Non-Critical
+
+```
+Critical features (payment, auth):
+- Full TEA Integrated workflow
+- Risk assessment, ATDD, quality gates
+- High confidence required
+
+Non-critical features (UI tweaks):
+- TEA Lite or No TEA
+- Quick tests, minimal overhead
+- Move fast
+```
+
+## Technical Implementation
+
+Each model uses different TEA workflows. See:
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Model details
+- [TEA Command Reference](/docs/reference/tea/commands.md) - Workflow reference
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Setup options
+
+## Related Concepts
+
+**Core TEA Concepts:**
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Risk assessment in different models
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - Quality across all models
+- [Knowledge Base System](/docs/explanation/tea/knowledge-base-system.md) - Consistent patterns across models
+
+**Technical Patterns:**
+- [Fixture Architecture](/docs/explanation/tea/fixture-architecture.md) - Infrastructure in different models
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Reliability in all models
+
+**Overview:**
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - 5 engagement models with cheat sheets
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - Design philosophy
+
+## Practical Guides
+
+**Getting Started:**
+- [TEA Lite Quickstart Tutorial](/docs/tutorials/getting-started/tea-lite-quickstart.md) - Model 3: TEA Lite
+
+**Use-Case Guides:**
+- [Using TEA with Existing Tests](/docs/how-to/brownfield/use-tea-with-existing-tests.md) - Model 5: Brownfield
+- [Running TEA for Enterprise](/docs/how-to/brownfield/use-tea-for-enterprise.md) - Enterprise integration
+
+**All Workflow Guides:**
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md) - Used in TEA Solo and Integrated
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md)
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md)
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md)
+- [How to Run Trace](/docs/how-to/workflows/run-trace.md)
+
+## Reference
+
+- [TEA Command Reference](/docs/reference/tea/commands.md) - All workflows explained
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Config per model
+- [Glossary](/docs/reference/glossary/index.md#test-architect-tea-concepts) - TEA Lite, TEA Solo, TEA Integrated terms
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/explanation/tea/fixture-architecture.md

@@ -0,0 +1,457 @@
+---
+title: "Fixture Architecture Explained"
+description: Understanding TEA's pure function → fixture → composition pattern for reusable test utilities
+---
+
+# Fixture Architecture Explained
+
+Fixture architecture is TEA's pattern for building reusable, testable, and composable test utilities. The core principle: build pure functions first, wrap in framework fixtures second.
+
+## Overview
+
+**The Pattern:**
+1. Write utility as pure function (unit-testable)
+2. Wrap in framework fixture (Playwright, Cypress)
+3. Compose fixtures with mergeTests (combine capabilities)
+4. Package for reuse across projects
+
+**Why this order?**
+- Pure functions are easier to test
+- Fixtures depend on framework (less portable)
+- Composition happens at fixture level
+- Reusability maximized
+
+### Fixture Architecture Flow
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': { 'fontSize':'14px'}}}%%
+flowchart TD
+    Start([Testing Need]) --> Pure[Step 1: Pure Function<br/>helpers/api-request.ts]
+    Pure -->|Unit testable<br/>Framework agnostic| Fixture[Step 2: Fixture Wrapper<br/>fixtures/api-request.ts]
+    Fixture -->|Injects framework<br/>dependencies| Compose[Step 3: Composition<br/>fixtures/index.ts]
+    Compose -->|mergeTests| Use[Step 4: Use in Tests<br/>tests/**.spec.ts]
+
+    Pure -.->|Can test in isolation| UnitTest[Unit Tests<br/>No framework needed]
+    Fixture -.->|Reusable pattern| Other[Other Projects<br/>Package export]
+    Compose -.->|Combine utilities| Multi[Multiple Fixtures<br/>One test]
+
+    style Pure fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
+    style Fixture fill:#fff3e0,stroke:#e65100,stroke-width:2px
+    style Compose fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px
+    style Use fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
+    style UnitTest fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px
+    style Other fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px
+    style Multi fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px
+```
+
+**Benefits at Each Step:**
+1. **Pure Function:** Testable, portable, reusable
+2. **Fixture:** Framework integration, clean API
+3. **Composition:** Combine capabilities, flexible
+4. **Usage:** Simple imports, type-safe
+
+## The Problem
+
+### Framework-First Approach (Common Anti-Pattern)
+
+```typescript
+// ❌ Bad: Built as fixture from the start
+export const test = base.extend({
+  apiRequest: async ({ request }, use) => {
+    await use(async (options) => {
+      const response = await request.fetch(options.url, {
+        method: options.method,
+        data: options.data
+      });
+
+      if (!response.ok()) {
+        throw new Error(`API request failed: ${response.status()}`);
+      }
+
+      return response.json();
+    });
+  }
+});
+```
+
+**Problems:**
+- Cannot unit test (requires Playwright context)
+- Tied to framework (not reusable in other tools)
+- Hard to compose with other fixtures
+- Difficult to mock for testing the utility itself
+
+### Copy-Paste Utilities
+
+```typescript
+// test-1.spec.ts
+test('test 1', async ({ request }) => {
+  const response = await request.post('/api/users', { data: {...} });
+  const body = await response.json();
+  if (!response.ok()) throw new Error('Failed');
+  // ... repeated in every test
+});
+
+// test-2.spec.ts
+test('test 2', async ({ request }) => {
+  const response = await request.post('/api/users', { data: {...} });
+  const body = await response.json();
+  if (!response.ok()) throw new Error('Failed');
+  // ... same code repeated
+});
+```
+
+**Problems:**
+- Code duplication (violates DRY)
+- Inconsistent error handling
+- Hard to update (change 50 tests)
+- No shared behavior
+
+## The Solution: Three-Step Pattern
+
+### Step 1: Pure Function
+
+```typescript
+// helpers/api-request.ts
+
+/**
+ * Make API request with automatic error handling
+ * Pure function - no framework dependencies
+ */
+export async function apiRequest({
+  request,  // Passed in (dependency injection)
+  method,
+  url,
+  data,
+  headers = {}
+}: ApiRequestParams): Promise<ApiResponse> {
+  const response = await request.fetch(url, {
+    method,
+    data,
+    headers
+  });
+
+  if (!response.ok()) {
+    throw new Error(`API request failed: ${response.status()}`);
+  }
+
+  return {
+    status: response.status(),
+    body: await response.json()
+  };
+}
+
+// ✅ Can unit test this function!
+describe('apiRequest', () => {
+  it('should throw on non-OK response', async () => {
+    const mockRequest = {
+      fetch: vi.fn().mockResolvedValue({ ok: () => false, status: () => 500 })
+    };
+
+    await expect(apiRequest({
+      request: mockRequest,
+      method: 'GET',
+      url: '/api/test'
+    })).rejects.toThrow('API request failed: 500');
+  });
+});
+```
+
+**Benefits:**
+- Unit testable (mock dependencies)
+- Framework-agnostic (works with any HTTP client)
+- Easy to reason about (pure function)
+- Portable (can use in Node scripts, CLI tools)
+
+### Step 2: Fixture Wrapper
+
+```typescript
+// fixtures/api-request.ts
+import { test as base } from '@playwright/test';
+import { apiRequest as apiRequestFn } from '../helpers/api-request';
+
+/**
+ * Playwright fixture wrapping the pure function
+ */
+export const test = base.extend<{ apiRequest: typeof apiRequestFn }>({
+  apiRequest: async ({ request }, use) => {
+    // Inject framework dependency (request)
+    await use((params) => apiRequestFn({ request, ...params }));
+  }
+});
+
+export { expect } from '@playwright/test';
+```
+
+**Benefits:**
+- Fixture provides framework context (request)
+- Pure function handles logic
+- Clean separation of concerns
+- Can swap frameworks (Cypress, etc.) by changing wrapper only
+
+### Step 3: Composition with mergeTests
+
+```typescript
+// fixtures/index.ts
+import { mergeTests } from '@playwright/test';
+import { test as apiRequestTest } from './api-request';
+import { test as authSessionTest } from './auth-session';
+import { test as logTest } from './log';
+
+/**
+ * Compose all fixtures into one test
+ */
+export const test = mergeTests(
+  apiRequestTest,
+  authSessionTest,
+  logTest
+);
+
+export { expect } from '@playwright/test';
+```
+
+**Usage:**
+```typescript
+// tests/profile.spec.ts
+import { test, expect } from '../support/fixtures';
+
+test('should update profile', async ({ apiRequest, authToken, log }) => {
+  log.info('Starting profile update test');
+
+  // Use API request fixture (matches pure function signature)
+  const { status, body } = await apiRequest({
+    method: 'PATCH',
+    url: '/api/profile',  
+    data: { name: 'New Name' },  
+    headers: { Authorization: `Bearer ${authToken}` }
+  });
+
+  expect(status).toBe(200);
+  expect(body.name).toBe('New Name');
+
+  log.info('Profile updated successfully');
+});
+```
+
+**Note:** This example uses the vanilla pure function signature (`url`, `data`). Playwright Utils uses different parameter names (`path`, `body`). See [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) for the utilities API.
+
+**Note:** `authToken` requires auth-session fixture setup with provider configuration. See [auth-session documentation](https://seontechnologies.github.io/playwright-utils/auth-session.html).
+
+**Benefits:**
+- Use multiple fixtures in one test
+- No manual composition needed
+- Type-safe (TypeScript knows all fixture types)
+- Clean imports
+
+## How It Works in TEA
+
+### TEA Generates This Pattern
+
+When you run `*framework` with `tea_use_playwright_utils: true`:
+
+**TEA scaffolds:**
+```
+tests/
+├── support/
+│   ├── helpers/           # Pure functions
+│   │   ├── api-request.ts
+│   │   └── auth-session.ts
+│   └── fixtures/          # Framework wrappers
+│       ├── api-request.ts
+│       ├── auth-session.ts
+│       └── index.ts       # Composition
+└── e2e/
+    └── example.spec.ts      # Uses composed fixtures
+```
+
+### TEA Reviews Against This Pattern
+
+When you run `*test-review`:
+
+**TEA checks:**
+- Are utilities pure functions? ✓
+- Are fixtures minimal wrappers? ✓
+- Is composition used? ✓
+- Can utilities be unit tested? ✓
+
+## Package Export Pattern
+
+### Make Fixtures Reusable Across Projects
+
+**Option 1: Build Your Own (Vanilla)**
+```json
+// package.json
+{
+  "name": "@company/test-utils",
+  "exports": {
+    "./api-request": "./fixtures/api-request.ts",
+    "./auth-session": "./fixtures/auth-session.ts",
+    "./log": "./fixtures/log.ts"
+  }
+}
+```
+
+**Usage:**
+```typescript
+import { test as apiTest } from '@company/test-utils/api-request';
+import { test as authTest } from '@company/test-utils/auth-session';
+import { mergeTests } from '@playwright/test';
+
+export const test = mergeTests(apiTest, authTest);
+```
+
+**Option 2: Use Playwright Utils (Recommended)**
+```bash
+npm install -D @seontechnologies/playwright-utils
+```
+
+**Usage:**
+```typescript
+import { test as base } from '@playwright/test';
+import { mergeTests } from '@playwright/test';
+import { test as apiRequestFixture } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { createAuthFixtures } from '@seontechnologies/playwright-utils/auth-session';
+
+const authFixtureTest = base.extend(createAuthFixtures());
+export const test = mergeTests(apiRequestFixture, authFixtureTest);
+// Production-ready utilities, battle-tested!
+```
+
+**Note:** Auth-session requires provider configuration. See [auth-session setup guide](https://seontechnologies.github.io/playwright-utils/auth-session.html).
+
+**Why Playwright Utils:**
+- Already built, tested, and maintained
+- Consistent patterns across projects
+- 11 utilities available (API, auth, network, logging, files)
+- Community support and documentation
+- Regular updates and improvements
+
+**When to Build Your Own:**
+- Company-specific patterns
+- Custom authentication systems
+- Unique requirements not covered by utilities
+
+## Comparison: Good vs Bad Patterns
+
+### Anti-Pattern: God Fixture
+
+```typescript
+// ❌ Bad: Everything in one fixture
+export const test = base.extend({
+  testUtils: async ({ page, request, context }, use) => {
+    await use({
+      // 50 different methods crammed into one fixture
+      apiRequest: async (...) => { },
+      login: async (...) => { },
+      createUser: async (...) => { },
+      deleteUser: async (...) => { },
+      uploadFile: async (...) => { },
+      // ... 45 more methods
+    });
+  }
+});
+```
+
+**Problems:**
+- Cannot test individual utilities
+- Cannot compose (all-or-nothing)
+- Cannot reuse specific utilities
+- Hard to maintain (1000+ line file)
+
+### Good Pattern: Single-Concern Fixtures
+
+```typescript
+// ✅ Good: One concern per fixture
+
+// api-request.ts
+export const test = base.extend({ apiRequest });
+
+// auth-session.ts
+export const test = base.extend({ authSession });
+
+// log.ts
+export const test = base.extend({ log });
+
+// Compose as needed
+import { mergeTests } from '@playwright/test';
+export const test = mergeTests(apiRequestTest, authSessionTest, logTest);
+```
+
+**Benefits:**
+- Each fixture is unit-testable
+- Compose only what you need
+- Reuse individual fixtures
+- Easy to maintain (small files)
+
+## Technical Implementation
+
+For detailed fixture architecture patterns, see the knowledge base:
+- [Knowledge Base Index - Architecture & Fixtures](/docs/reference/tea/knowledge-base.md)
+- [Complete Knowledge Base Index](/docs/reference/tea/knowledge-base.md)
+
+## When to Use This Pattern
+
+### Always Use For:
+
+**Reusable utilities:**
+- API request helpers
+- Authentication handlers
+- File operations
+- Network mocking
+
+**Test infrastructure:**
+- Shared fixtures across teams
+- Packaged utilities (playwright-utils)
+- Company-wide test standards
+
+### Consider Skipping For:
+
+**One-off test setup:**
+```typescript
+// Simple one-time setup - inline is fine
+test.beforeEach(async ({ page }) => {
+  await page.goto('/');
+  await page.click('#accept-cookies');
+});
+```
+
+**Test-specific helpers:**
+```typescript
+// Used in one test file only - keep local
+function createTestUser(name: string) {
+  return { name, email: `${name}@test.com` };
+}
+```
+
+## Related Concepts
+
+**Core TEA Concepts:**
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - Quality standards fixtures enforce
+- [Knowledge Base System](/docs/explanation/tea/knowledge-base-system.md) - Fixture patterns in knowledge base
+
+**Technical Patterns:**
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Network fixtures explained
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Fixture complexity matches risk
+
+**Overview:**
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Fixture architecture in workflows
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - Why fixtures matter
+
+## Practical Guides
+
+**Setup Guides:**
+- [How to Set Up Test Framework](/docs/how-to/workflows/setup-test-framework.md) - TEA scaffolds fixtures
+- [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) - Production-ready fixtures
+
+**Workflow Guides:**
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md) - Using fixtures in tests
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md) - Fixture composition examples
+
+## Reference
+
+- [TEA Command Reference](/docs/reference/tea/commands.md) - *framework command
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - Fixture architecture fragments
+- [Glossary](/docs/reference/glossary/index.md#test-architect-tea-concepts) - Fixture architecture term
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/explanation/tea/knowledge-base-system.md

@@ -0,0 +1,554 @@
+---
+title: "Knowledge Base System Explained"
+description: Understanding how TEA uses tea-index.csv for context engineering and consistent test quality
+---
+
+# Knowledge Base System Explained
+
+TEA's knowledge base system is how context engineering works - automatically loading domain-specific standards into AI context so tests are consistently high-quality regardless of prompt variation.
+
+## Overview
+
+**The Problem:** AI without context produces inconsistent results.
+
+**Traditional approach:**
+```
+User: "Write tests for login"
+AI: [Generates tests with random quality]
+- Sometimes uses hard waits
+- Sometimes uses good patterns
+- Inconsistent across sessions
+- Quality depends on prompt
+```
+
+**TEA with knowledge base:**
+```
+User: "Write tests for login"
+TEA: [Loads test-quality.md, network-first.md, auth-session.md]
+TEA: [Generates tests following established patterns]
+- Always uses network-first patterns
+- Always uses proper fixtures
+- Consistent across all sessions
+- Quality independent of prompt
+```
+
+**Result:** Systematic quality, not random chance.
+
+## The Problem
+
+### Prompt-Driven Testing = Inconsistency
+
+**Session 1:**
+```
+User: "Write tests for profile editing"
+
+AI: [No context loaded]
+// Generates test with hard waits
+await page.waitForTimeout(3000);
+```
+
+**Session 2:**
+```
+User: "Write comprehensive tests for profile editing with best practices"
+
+AI: [Still no systematic context]
+// Generates test with some improvements, but still issues
+await page.waitForSelector('.success', { timeout: 10000 });
+```
+
+**Session 3:**
+```
+User: "Write tests using network-first patterns and proper fixtures"
+
+AI: [Better prompt, but still reinventing patterns]
+// Generates test with network-first, but inconsistent with other tests
+```
+
+**Problem:** Quality depends on prompt engineering skill, no consistency.
+
+### Knowledge Drift
+
+Without a knowledge base:
+- Team A uses pattern X
+- Team B uses pattern Y
+- Both work, but inconsistent
+- No single source of truth
+- Patterns drift over time
+
+## The Solution: tea-index.csv Manifest
+
+### How It Works
+
+**1. Manifest Defines Fragments**
+
+`src/modules/bmm/testarch/tea-index.csv`:
+```csv
+id,name,description,tags,fragment_file
+test-quality,Test Quality,Execution limits and isolation rules,quality;standards,knowledge/test-quality.md
+network-first,Network-First Safeguards,Intercept-before-navigate workflow,network;stability,knowledge/network-first.md
+fixture-architecture,Fixture Architecture,Composable fixture patterns,fixtures;architecture,knowledge/fixture-architecture.md
+```
+
+**2. Workflow Loads Relevant Fragments**
+
+When user runs `*atdd`:
+```
+TEA reads tea-index.csv
+Identifies fragments needed for ATDD:
+- test-quality.md (quality standards)
+- network-first.md (avoid flakiness)
+- component-tdd.md (TDD patterns)
+- fixture-architecture.md (reusable fixtures)
+- data-factories.md (test data)
+
+Loads only these 5 fragments (not all 33)
+Generates tests following these patterns
+```
+
+**3. Consistent Output**
+
+Every time `*atdd` runs:
+- Same fragments loaded
+- Same patterns applied
+- Same quality standards
+- Consistent test structure
+
+**Result:** Tests look like they were written by the same expert, every time.
+
+### Knowledge Base Loading Diagram
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': { 'fontSize':'14px'}}}%%
+flowchart TD
+    User([User: *atdd]) --> Workflow[TEA Workflow<br/>Triggered]
+    Workflow --> Read[Read Manifest<br/>tea-index.csv]
+
+    Read --> Identify{Identify Relevant<br/>Fragments for ATDD}
+
+    Identify -->|Needed| L1[✓ test-quality.md]
+    Identify -->|Needed| L2[✓ network-first.md]
+    Identify -->|Needed| L3[✓ component-tdd.md]
+    Identify -->|Needed| L4[✓ data-factories.md]
+    Identify -->|Needed| L5[✓ fixture-architecture.md]
+
+    Identify -.->|Skip| S1[✗ contract-testing.md]
+    Identify -.->|Skip| S2[✗ burn-in.md]
+    Identify -.->|Skip| S3[+ 26 other fragments]
+
+    L1 --> Context[AI Context<br/>5 fragments loaded]
+    L2 --> Context
+    L3 --> Context
+    L4 --> Context
+    L5 --> Context
+
+    Context --> Gen[Generate Tests<br/>Following patterns]
+    Gen --> Out([Consistent Output<br/>Same quality every time])
+
+    style User fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
+    style Read fill:#fff3e0,stroke:#e65100,stroke-width:2px
+    style L1 fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
+    style L2 fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
+    style L3 fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
+    style L4 fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
+    style L5 fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px
+    style S1 fill:#e0e0e0,stroke:#616161,stroke-width:1px
+    style S2 fill:#e0e0e0,stroke:#616161,stroke-width:1px
+    style S3 fill:#e0e0e0,stroke:#616161,stroke-width:1px
+    style Context fill:#f3e5f5,stroke:#6a1b9a,stroke-width:3px
+    style Out fill:#4caf50,stroke:#1b5e20,stroke-width:3px,color:#fff
+```
+
+## Fragment Structure
+
+### Anatomy of a Fragment
+
+Each fragment follows this structure:
+
+```markdown
+# Fragment Name
+
+## Principle
+[One sentence - what is this pattern?]
+
+## Rationale
+[Why use this instead of alternatives?]
+Why this pattern exists
+Problems it solves
+Benefits it provides
+
+## Pattern Examples
+
+### Example 1: Basic Usage
+```code
+[Runnable code example]
+```
+[Explanation of example]
+
+### Example 2: Advanced Pattern
+```code
+[More complex example]
+```
+[Explanation]
+
+## Anti-Patterns
+
+### Don't Do This
+```code
+[Bad code example]
+```
+[Why it's bad]
+[What breaks]
+
+## Related Patterns
+- [Link to related fragment]
+```
+
+<!-- markdownlint-disable MD024 -->
+### Example: test-quality.md Fragment
+
+```markdown
+# Test Quality
+
+## Principle
+Tests must be deterministic, isolated, explicit, focused, and fast.
+
+## Rationale
+Tests that fail randomly, depend on each other, or take too long lose team trust.
+[... detailed explanation ...]
+
+## Pattern Examples
+
+### Example 1: Deterministic Test
+```typescript
+// ✅ Wait for actual response, not timeout
+const promise = page.waitForResponse(matcher);
+await page.click('button');
+await promise;
+```
+
+### Example 2: Isolated Test
+```typescript
+// ✅ Self-cleaning test
+test('test', async ({ page }) => {
+  const userId = await createTestUser();
+  // ... test logic ...
+  await deleteTestUser(userId);  // Cleanup
+});
+```
+
+## Anti-Patterns
+
+### Hard Waits
+```typescript
+// ❌ Non-deterministic
+await page.waitForTimeout(3000);
+```
+[Why this causes flakiness]
+```
+
+**Total:** 24.5 KB, 12 code examples
+<!-- markdownlint-enable MD024 -->
+
+## How TEA Uses the Knowledge Base
+
+### Workflow-Specific Loading
+
+**Different workflows load different fragments:**
+
+| Workflow | Fragments Loaded | Purpose |
+|----------|-----------------|---------|
+| `*framework` | fixture-architecture, playwright-config, fixtures-composition | Infrastructure patterns |
+| `*test-design` | test-quality, test-priorities-matrix, risk-governance | Planning standards |
+| `*atdd` | test-quality, component-tdd, network-first, data-factories | TDD patterns |
+| `*automate` | test-quality, test-levels-framework, selector-resilience | Comprehensive generation |
+| `*test-review` | All quality/resilience/debugging fragments | Full audit patterns |
+| `*ci` | ci-burn-in, burn-in, selective-testing | CI/CD optimization |
+
+**Benefit:** Only load what's needed (focused context, no bloat).
+
+### Dynamic Fragment Selection
+
+TEA doesn't load all 33 fragments at once:
+
+```
+User runs: *atdd for authentication feature
+
+TEA analyzes context:
+- Feature type: Authentication
+- Relevant fragments:
+  - test-quality.md (always loaded)
+  - auth-session.md (auth patterns)
+  - network-first.md (avoid flakiness)
+  - email-auth.md (if email-based auth)
+  - data-factories.md (test users)
+
+Skips:
+- contract-testing.md (not relevant)
+- feature-flags.md (not relevant)
+- file-utils.md (not relevant)
+
+Result: 5 relevant fragments loaded, 28 skipped
+```
+
+**Benefit:** Focused context = better results, lower token usage.
+
+## Context Engineering in Practice
+
+### Example: Consistent Test Generation
+
+**Without Knowledge Base (Vanilla Playwright, Random Quality):**
+```
+Session 1: User runs *atdd
+AI: [Guesses patterns from general knowledge]
+
+Generated:
+test('api test', async ({ request }) => {
+  const response = await request.get('/api/users');
+  await page.waitForTimeout(2000);  // Hard wait
+  const users = await response.json();
+  // Random quality
+});
+
+Session 2: User runs *atdd (different day)
+AI: [Different random patterns]
+
+Generated:
+test('api test', async ({ request }) => {
+  const response = await request.get('/api/users');
+  const users = await response.json();
+  // Better but inconsistent
+});
+
+Result: Inconsistent quality, random patterns
+```
+
+**With Knowledge Base (TEA + Playwright Utils):**
+```
+Session 1: User runs *atdd
+TEA: [Loads test-quality.md, network-first.md, api-request.md from tea-index.csv]
+
+Generated:
+import { test } from '@seontechnologies/playwright-utils/api-request/fixtures';
+
+test('should fetch users', async ({ apiRequest }) => {
+  const { status, body } = await apiRequest({
+    method: 'GET',
+    path: '/api/users'
+  }).validateSchema(UsersSchema);  // Chained validation
+
+  expect(status).toBe(200);
+  expect(body).toBeInstanceOf(Array);
+});
+
+Session 2: User runs *atdd (different day)
+TEA: [Loads same fragments from tea-index.csv]
+
+Generated: Identical pattern, same quality
+
+Result: Systematic quality, established patterns (ALWAYS uses apiRequest utility when playwright-utils enabled)
+```
+
+**Key Difference:**
+- **Without KB:** Random patterns, inconsistent APIs
+- **With KB:** Always uses `apiRequest` utility, always validates schemas, always returns `{ status, body }`
+
+### Example: Test Review Consistency
+
+**Without Knowledge Base:**
+```
+*test-review session 1:
+"This test looks okay" [50 issues missed]
+
+*test-review session 2:
+"This test has some issues" [Different issues flagged]
+
+Result: Inconsistent feedback
+```
+
+**With Knowledge Base:**
+```
+*test-review session 1:
+[Loads all quality fragments]
+Flags: 12 hard waits, 5 conditionals (based on test-quality.md)
+
+*test-review session 2:
+[Loads same fragments]
+Flags: Same issues with same explanations
+
+Result: Consistent, reliable feedback
+```
+
+## Maintaining the Knowledge Base
+
+### When to Add a Fragment
+
+**Good reasons:**
+- Pattern is used across multiple workflows
+- Standard is non-obvious (needs documentation)
+- Team asks "how should we handle X?" repeatedly
+- New tool integration (e.g., new testing library)
+
+**Bad reasons:**
+- One-off pattern (document in test file instead)
+- Obvious pattern (everyone knows this)
+- Experimental (not proven yet)
+
+### Fragment Quality Standards
+
+**Good fragment:**
+- Principle stated in one sentence
+- Rationale explains why clearly
+- 3+ pattern examples with code
+- Anti-patterns shown (what not to do)
+- Self-contained (minimal dependencies)
+
+**Example size:** 10-30 KB optimal
+
+### Updating Existing Fragments
+
+**When to update:**
+- Pattern evolved (better approach discovered)
+- Tool updated (new Playwright API)
+- Team feedback (pattern unclear)
+- Bug in example code
+
+**How to update:**
+1. Edit fragment markdown file
+2. Update examples
+3. Test with affected workflows
+4. Ensure no breaking changes
+
+**No need to update tea-index.csv** unless description/tags change.
+
+## Benefits of Knowledge Base System
+
+### 1. Consistency
+
+**Before:** Test quality varies by who wrote it
+**After:** All tests follow same patterns (TEA-generated or reviewed)
+
+### 2. Onboarding
+
+**Before:** New team member reads 20 documents, asks 50 questions
+**After:** New team member runs `*atdd`, sees patterns in generated code, learns by example
+
+### 3. Quality Gates
+
+**Before:** "Is this test good?" → subjective opinion
+**After:** "*test-review" → objective score against knowledge base
+
+### 4. Pattern Evolution
+
+**Before:** Update tests manually across 100 files
+**After:** Update fragment once, all new tests use new pattern
+
+### 5. Cross-Project Reuse
+
+**Before:** Reinvent patterns for each project
+**After:** Same fragments across all BMad projects (consistency at scale)
+
+## Comparison: With vs Without Knowledge Base
+
+### Scenario: Testing Async Background Job
+
+**Without Knowledge Base:**
+
+Developer 1:
+```typescript
+// Uses hard wait
+await page.click('button');
+await page.waitForTimeout(10000);  // Hope job finishes
+```
+
+Developer 2:
+```typescript
+// Uses polling
+await page.click('button');
+for (let i = 0; i < 10; i++) {
+  const status = await page.locator('.status').textContent();
+  if (status === 'complete') break;
+  await page.waitForTimeout(1000);
+}
+```
+
+Developer 3:
+```typescript
+// Uses waitForSelector
+await page.click('button');
+await page.waitForSelector('.success', { timeout: 30000 });
+```
+
+**Result:** 3 different patterns, all suboptimal.
+
+**With Knowledge Base (recurse.md fragment):**
+
+All developers:
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+
+test('job completion', async ({ apiRequest, recurse }) => {
+  // Start async job
+  const { body: job } = await apiRequest({
+    method: 'POST',
+    path: '/api/jobs'
+  });
+
+  // Poll until complete (correct API: command, predicate, options)
+  const result = await recurse(
+    () => apiRequest({ method: 'GET', path: `/api/jobs/${job.id}` }),
+    (response) => response.body.status === 'completed',  // response.body from apiRequest
+    {
+      timeout: 30000,
+      interval: 2000,
+      log: 'Waiting for job to complete'
+    }
+  );
+
+  expect(result.body.status).toBe('completed');
+});
+```
+
+**Result:** Consistent pattern using correct playwright-utils API (command, predicate, options).
+
+## Technical Implementation
+
+For details on the knowledge base index, see:
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md)
+- [TEA Configuration](/docs/reference/tea/configuration.md)
+
+## Related Concepts
+
+**Core TEA Concepts:**
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - Standards in knowledge base
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Risk patterns in knowledge base
+- [Engagement Models](/docs/explanation/tea/engagement-models.md) - Knowledge base across all models
+
+**Technical Patterns:**
+- [Fixture Architecture](/docs/explanation/tea/fixture-architecture.md) - Fixture patterns in knowledge base
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Network patterns in knowledge base
+
+**Overview:**
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Knowledge base in workflows
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - **Foundation: Context engineering philosophy** (why knowledge base solves AI test problems)
+
+## Practical Guides
+
+**All Workflow Guides Use Knowledge Base:**
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md)
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md)
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md)
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md)
+
+**Integration:**
+- [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) - PW-Utils in knowledge base
+
+## Reference
+
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - Complete fragment index
+- [TEA Command Reference](/docs/reference/tea/commands.md) - Which workflows load which fragments
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Config affects fragment loading
+- [Glossary](/docs/reference/glossary/index.md#test-architect-tea-concepts) - Context engineering, knowledge fragment terms
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/explanation/tea/network-first-patterns.md

@@ -0,0 +1,853 @@
+---
+title: "Network-First Patterns Explained"
+description: Understanding how TEA eliminates test flakiness by waiting for actual network responses
+---
+
+# Network-First Patterns Explained
+
+Network-first patterns are TEA's solution to test flakiness. Instead of guessing how long to wait with fixed timeouts, wait for the actual network event that causes UI changes.
+
+## Overview
+
+**The Core Principle:**
+UI changes because APIs respond. Wait for the API response, not an arbitrary timeout.
+
+**Traditional approach:**
+```typescript
+await page.click('button');
+await page.waitForTimeout(3000);  // Hope 3 seconds is enough
+await expect(page.locator('.success')).toBeVisible();
+```
+
+**Network-first approach:**
+```typescript
+const responsePromise = page.waitForResponse(
+  resp => resp.url().includes('/api/submit') && resp.ok()
+);
+await page.click('button');
+await responsePromise;  // Wait for actual response
+await expect(page.locator('.success')).toBeVisible();
+```
+
+**Result:** Deterministic tests that wait exactly as long as needed.
+
+## The Problem
+
+### Hard Waits Create Flakiness
+
+```typescript
+// ❌ The flaky test pattern
+test('should submit form', async ({ page }) => {
+  await page.fill('#name', 'Test User');
+  await page.click('button[type="submit"]');
+
+  await page.waitForTimeout(2000);  // Wait 2 seconds
+
+  await expect(page.locator('.success')).toBeVisible();
+});
+```
+
+**Why this fails:**
+- **Fast network:** Wastes 1.5 seconds waiting
+- **Slow network:** Not enough time, test fails
+- **CI environment:** Slower than local, fails randomly
+- **Under load:** API takes 3 seconds, test fails
+
+**Result:** "Works on my machine" syndrome, flaky CI.
+
+### The Timeout Escalation Trap
+
+```typescript
+// Developer sees flaky test
+await page.waitForTimeout(2000);  // Failed in CI
+
+// Increases timeout
+await page.waitForTimeout(5000);  // Still fails sometimes
+
+// Increases again
+await page.waitForTimeout(10000);  // Now it passes... slowly
+
+// Problem: Now EVERY test waits 10 seconds
+// Suite that took 5 minutes now takes 30 minutes
+```
+
+**Result:** Slow, still-flaky tests.
+
+### Race Conditions
+
+```typescript
+// ❌ Navigate-then-wait race condition
+test('should load dashboard data', async ({ page }) => {
+  await page.goto('/dashboard');  // Navigation starts
+
+  // Race condition! API might not have responded yet
+  await expect(page.locator('.data-table')).toBeVisible();
+});
+```
+
+**What happens:**
+1. `goto()` starts navigation
+2. Page loads HTML
+3. JavaScript requests `/api/dashboard`
+4. Test checks for `.data-table` BEFORE API responds
+5. Test fails intermittently
+
+**Result:** "Sometimes it works, sometimes it doesn't."
+
+## The Solution: Intercept-Before-Navigate
+
+### Wait for Response Before Asserting
+
+```typescript
+// ✅ Good: Network-first pattern
+test('should load dashboard data', async ({ page }) => {
+  // Set up promise BEFORE navigation
+  const dashboardPromise = page.waitForResponse(
+    resp => resp.url().includes('/api/dashboard') && resp.ok()
+  );
+
+  // Navigate
+  await page.goto('/dashboard');
+
+  // Wait for API response
+  const response = await dashboardPromise;
+  const data = await response.json();
+
+  // Now assert UI
+  await expect(page.locator('.data-table')).toBeVisible();
+  await expect(page.locator('.data-table tr')).toHaveCount(data.items.length);
+});
+```
+
+**Why this works:**
+- Wait set up BEFORE navigation (no race)
+- Wait for actual API response (deterministic)
+- No fixed timeout (fast when API is fast)
+- Validates API response (catch backend errors)
+
+**With Playwright Utils (Even Cleaner):**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+import { expect } from '@playwright/test';
+
+test('should load dashboard data', async ({ page, interceptNetworkCall }) => {
+  // Set up interception BEFORE navigation
+  const dashboardCall = interceptNetworkCall({
+    method: 'GET',
+    url: '**/api/dashboard'
+  });
+
+  // Navigate
+  await page.goto('/dashboard');
+
+  // Wait for API response (automatic JSON parsing)
+  const { status, responseJson: data } = await dashboardCall;
+
+  // Validate API response
+  expect(status).toBe(200);
+  expect(data.items).toBeDefined();
+
+  // Assert UI matches API data
+  await expect(page.locator('.data-table')).toBeVisible();
+  await expect(page.locator('.data-table tr')).toHaveCount(data.items.length);
+});
+```
+
+**Playwright Utils Benefits:**
+- Automatic JSON parsing (no `await response.json()`)
+- Returns `{ status, responseJson, requestJson }` structure
+- Cleaner API (no need to check `resp.ok()`)
+- Same intercept-before-navigate pattern
+
+### Intercept-Before-Navigate Pattern
+
+**Key insight:** Set up wait BEFORE triggering the action.
+
+```typescript
+// ✅ Pattern: Intercept → Action → Await
+
+// 1. Intercept (set up wait)
+const promise = page.waitForResponse(matcher);
+
+// 2. Action (trigger request)
+await page.click('button');
+
+// 3. Await (wait for actual response)
+await promise;
+```
+
+**Why this order:**
+- `waitForResponse()` starts listening immediately
+- Then trigger the action that makes the request
+- Then wait for the promise to resolve
+- No race condition possible
+
+#### Intercept-Before-Navigate Flow
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': { 'fontSize':'14px'}}}%%
+sequenceDiagram
+    participant Test
+    participant Playwright
+    participant Browser
+    participant API
+
+    rect rgb(200, 230, 201)
+        Note over Test,Playwright: ✅ CORRECT: Intercept First
+        Test->>Playwright: 1. waitForResponse(matcher)
+        Note over Playwright: Starts listening for response
+        Test->>Browser: 2. click('button')
+        Browser->>API: 3. POST /api/submit
+        API-->>Browser: 4. 200 OK {success: true}
+        Browser-->>Playwright: 5. Response captured
+        Test->>Playwright: 6. await promise
+        Playwright-->>Test: 7. Returns response
+        Note over Test: No race condition!
+    end
+
+    rect rgb(255, 205, 210)
+        Note over Test,API: ❌ WRONG: Action First
+        Test->>Browser: 1. click('button')
+        Browser->>API: 2. POST /api/submit
+        API-->>Browser: 3. 200 OK (already happened!)
+        Test->>Playwright: 4. waitForResponse(matcher)
+        Note over Test,Playwright: Too late - response already occurred
+        Note over Test: Race condition! Test hangs or fails
+    end
+```
+
+**Correct Order (Green):**
+1. Set up listener (`waitForResponse`)
+2. Trigger action (`click`)
+3. Wait for response (`await promise`)
+
+**Wrong Order (Red):**
+1. Trigger action first
+2. Set up listener too late
+3. Response already happened - missed!
+
+## How It Works in TEA
+
+### TEA Generates Network-First Tests
+
+**Vanilla Playwright:**
+```typescript
+// When you run *atdd or *automate, TEA generates:
+
+test('should create user', async ({ page }) => {
+  // TEA automatically includes network wait
+  const createUserPromise = page.waitForResponse(
+    resp => resp.url().includes('/api/users') &&
+            resp.request().method() === 'POST' &&
+            resp.ok()
+  );
+
+  await page.fill('#name', 'Test User');
+  await page.click('button[type="submit"]');
+
+  const response = await createUserPromise;
+  const user = await response.json();
+
+  // Validate both API and UI
+  expect(user.id).toBeDefined();
+  await expect(page.locator('.success')).toContainText(user.name);
+});
+```
+
+**With Playwright Utils (if `tea_use_playwright_utils: true`):**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+import { expect } from '@playwright/test';
+
+test('should create user', async ({ page, interceptNetworkCall }) => {
+  // TEA uses interceptNetworkCall for cleaner interception
+  const createUserCall = interceptNetworkCall({
+    method: 'POST',
+    url: '**/api/users'
+  });
+
+  await page.getByLabel('Name').fill('Test User');
+  await page.getByRole('button', { name: 'Submit' }).click();
+
+  // Wait for response (automatic JSON parsing)
+  const { status, responseJson: user } = await createUserCall;
+
+  // Validate both API and UI
+  expect(status).toBe(201);
+  expect(user.id).toBeDefined();
+  await expect(page.locator('.success')).toContainText(user.name);
+});
+```
+
+**Playwright Utils Benefits:**
+- Automatic JSON parsing (`responseJson` ready to use)
+- No manual `await response.json()`
+- Returns `{ status, responseJson }` structure
+- Cleaner, more readable code
+
+### TEA Reviews for Hard Waits
+
+When you run `*test-review`:
+
+```markdown
+## Critical Issue: Hard Wait Detected
+
+**File:** tests/e2e/submit.spec.ts:45
+**Issue:** Using `page.waitForTimeout(3000)`
+**Severity:** Critical (causes flakiness)
+
+**Current Code:**
+```typescript
+await page.click('button');
+await page.waitForTimeout(3000);  // ❌
+```
+
+**Fix:**
+```typescript
+const responsePromise = page.waitForResponse(
+  resp => resp.url().includes('/api/submit') && resp.ok()
+);
+await page.click('button');
+await responsePromise;  // ✅
+```
+
+**Why:** Hard waits are non-deterministic. Use network-first patterns.
+```
+
+## Pattern Variations
+
+### Basic Response Wait
+
+**Vanilla Playwright:**
+```typescript
+// Wait for any successful response
+const promise = page.waitForResponse(resp => resp.ok());
+await page.click('button');
+await promise;
+```
+
+**With Playwright Utils:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+
+test('basic wait', async ({ page, interceptNetworkCall }) => {
+  const responseCall = interceptNetworkCall({ url: '**' });  // Match any
+  await page.click('button');
+  const { status } = await responseCall;
+  expect(status).toBe(200);
+});
+```
+
+---
+
+### Specific URL Match
+
+**Vanilla Playwright:**
+```typescript
+// Wait for specific endpoint
+const promise = page.waitForResponse(
+  resp => resp.url().includes('/api/users/123')
+);
+await page.goto('/user/123');
+await promise;
+```
+
+**With Playwright Utils:**
+```typescript
+test('specific URL', async ({ page, interceptNetworkCall }) => {
+  const userCall = interceptNetworkCall({ url: '**/api/users/123' });
+  await page.goto('/user/123');
+  const { status, responseJson } = await userCall;
+  expect(status).toBe(200);
+});
+```
+
+---
+
+### Method + Status Match
+
+**Vanilla Playwright:**
+```typescript
+// Wait for POST that returns 201
+const promise = page.waitForResponse(
+  resp =>
+    resp.url().includes('/api/users') &&
+    resp.request().method() === 'POST' &&
+    resp.status() === 201
+);
+await page.click('button[type="submit"]');
+await promise;
+```
+
+**With Playwright Utils:**
+```typescript
+test('method and status', async ({ page, interceptNetworkCall }) => {
+  const createCall = interceptNetworkCall({
+    method: 'POST',
+    url: '**/api/users'
+  });
+  await page.click('button[type="submit"]');
+  const { status, responseJson } = await createCall;
+  expect(status).toBe(201);  // Explicit status check
+});
+```
+
+---
+
+### Multiple Responses
+
+**Vanilla Playwright:**
+```typescript
+// Wait for multiple API calls
+const [usersResp, postsResp] = await Promise.all([
+  page.waitForResponse(resp => resp.url().includes('/api/users')),
+  page.waitForResponse(resp => resp.url().includes('/api/posts')),
+  page.goto('/dashboard')  // Triggers both requests
+]);
+
+const users = await usersResp.json();
+const posts = await postsResp.json();
+```
+
+**With Playwright Utils:**
+```typescript
+test('multiple responses', async ({ page, interceptNetworkCall }) => {
+  const usersCall = interceptNetworkCall({ url: '**/api/users' });
+  const postsCall = interceptNetworkCall({ url: '**/api/posts' });
+
+  await page.goto('/dashboard');  // Triggers both
+
+  const [{ responseJson: users }, { responseJson: posts }] = await Promise.all([
+    usersCall,
+    postsCall
+  ]);
+
+  expect(users).toBeInstanceOf(Array);
+  expect(posts).toBeInstanceOf(Array);
+});
+```
+
+---
+
+### Validate Response Data
+
+**Vanilla Playwright:**
+```typescript
+// Verify API response before asserting UI
+const promise = page.waitForResponse(
+  resp => resp.url().includes('/api/checkout') && resp.ok()
+);
+
+await page.click('button:has-text("Complete Order")');
+
+const response = await promise;
+const order = await response.json();
+
+// Response validation
+expect(order.status).toBe('confirmed');
+expect(order.total).toBeGreaterThan(0);
+
+// UI validation
+await expect(page.locator('.order-confirmation')).toContainText(order.id);
+```
+
+**With Playwright Utils:**
+```typescript
+test('validate response data', async ({ page, interceptNetworkCall }) => {
+  const checkoutCall = interceptNetworkCall({
+    method: 'POST',
+    url: '**/api/checkout'
+  });
+
+  await page.click('button:has-text("Complete Order")');
+
+  const { status, responseJson: order } = await checkoutCall;
+
+  // Response validation (automatic JSON parsing)
+  expect(status).toBe(200);
+  expect(order.status).toBe('confirmed');
+  expect(order.total).toBeGreaterThan(0);
+
+  // UI validation
+  await expect(page.locator('.order-confirmation')).toContainText(order.id);
+});
+```
+
+## Advanced Patterns
+
+### HAR Recording for Offline Testing
+
+**Vanilla Playwright (Manual HAR Handling):**
+
+```typescript
+// First run: Record mode (saves HAR file)
+test('offline testing - RECORD', async ({ page, context }) => {
+  // Record mode: Save network traffic to HAR
+  await context.routeFromHAR('./hars/dashboard.har', {
+    url: '**/api/**',
+    update: true  // Update HAR file
+  });
+
+  await page.goto('/dashboard');
+  // All network traffic saved to dashboard.har
+});
+
+// Subsequent runs: Playback mode (uses saved HAR)
+test('offline testing - PLAYBACK', async ({ page, context }) => {
+  // Playback mode: Use saved network traffic
+  await context.routeFromHAR('./hars/dashboard.har', {
+    url: '**/api/**',
+    update: false  // Use existing HAR, no network calls
+  });
+
+  await page.goto('/dashboard');
+  // Uses recorded responses, no backend needed
+});
+```
+
+**With Playwright Utils (Automatic HAR Management):**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/network-recorder/fixtures';
+
+// Record mode: Set environment variable
+process.env.PW_NET_MODE = 'record';
+
+test('should work offline', async ({ page, context, networkRecorder }) => {
+  await networkRecorder.setup(context);  // Handles HAR automatically
+
+  await page.goto('/dashboard');
+  await page.click('#add-item');
+  // All network traffic recorded, CRUD operations detected
+});
+```
+
+**Switch to playback:**
+```bash
+# Playback mode (offline)
+PW_NET_MODE=playback npx playwright test
+# Uses HAR file, no backend needed!
+```
+
+**Playwright Utils Benefits:**
+- Automatic HAR file management (naming, paths)
+- CRUD operation detection (stateful mocking)
+- Environment variable control (easy switching)
+- Works for complex interactions (create, update, delete)
+- No manual route configuration
+
+### Network Request Interception
+
+**Vanilla Playwright:**
+```typescript
+test('should handle API error', async ({ page }) => {
+  // Manual route setup
+  await page.route('**/api/users', (route) => {
+    route.fulfill({
+      status: 500,
+      body: JSON.stringify({ error: 'Internal server error' })
+    });
+  });
+
+  await page.goto('/users');
+
+  const response = await page.waitForResponse('**/api/users');
+  const error = await response.json();
+
+  expect(error.error).toContain('Internal server');
+  await expect(page.locator('.error-message')).toContainText('Server error');
+});
+```
+
+**With Playwright Utils:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+
+test('should handle API error', async ({ page, interceptNetworkCall }) => {
+  // Stub API to return error (set up BEFORE navigation)
+  const usersCall = interceptNetworkCall({
+    method: 'GET',
+    url: '**/api/users',
+    fulfillResponse: {
+      status: 500,
+      body: { error: 'Internal server error' }
+    }
+  });
+
+  await page.goto('/users');
+
+  // Wait for mocked response and access parsed data
+  const { status, responseJson } = await usersCall;
+
+  expect(status).toBe(500);
+  expect(responseJson.error).toContain('Internal server');
+  await expect(page.locator('.error-message')).toContainText('Server error');
+});
+```
+
+**Playwright Utils Benefits:**
+- Automatic JSON parsing (`responseJson` ready to use)
+- Returns promise with `{ status, responseJson, requestJson }`
+- No need to pass `page` (auto-injected by fixture)
+- Glob pattern matching (simpler than regex)
+- Single declarative call (setup + wait in one)
+
+## Comparison: Traditional vs Network-First
+
+### Loading Dashboard Data
+
+**Traditional (Flaky):**
+```typescript
+test('dashboard loads data', async ({ page }) => {
+  await page.goto('/dashboard');
+  await page.waitForTimeout(2000);  // ❌ Magic number
+  await expect(page.locator('table tr')).toHaveCount(5);
+});
+```
+
+**Failure modes:**
+- API takes 2.5s → test fails
+- API returns 3 items not 5 → hard to debug (which issue?)
+- CI slower than local → fails in CI only
+
+**Network-First (Deterministic):**
+```typescript
+test('dashboard loads data', async ({ page }) => {
+  const apiPromise = page.waitForResponse(
+    resp => resp.url().includes('/api/dashboard') && resp.ok()
+  );
+
+  await page.goto('/dashboard');
+
+  const response = await apiPromise;
+  const { items } = await response.json();
+
+  // Validate API response
+  expect(items).toHaveLength(5);
+
+  // Validate UI matches API
+  await expect(page.locator('table tr')).toHaveCount(items.length);
+});
+```
+
+**Benefits:**
+- Waits exactly as long as needed (100ms or 5s, doesn't matter)
+- Validates API response (catch backend errors)
+- Validates UI matches API (catch frontend bugs)
+- Works in any environment (local, CI, staging)
+
+**With Playwright Utils (Even Better):**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+
+test('dashboard loads data', async ({ page, interceptNetworkCall }) => {
+  const dashboardCall = interceptNetworkCall({
+    method: 'GET',
+    url: '**/api/dashboard'
+  });
+
+  await page.goto('/dashboard');
+
+  const { status, responseJson: { items } } = await dashboardCall;
+
+  // Validate API response (automatic JSON parsing)
+  expect(status).toBe(200);
+  expect(items).toHaveLength(5);
+
+  // Validate UI matches API
+  await expect(page.locator('table tr')).toHaveCount(items.length);
+});
+```
+
+**Additional Benefits:**
+- No manual `await response.json()` (automatic parsing)
+- Cleaner destructuring of nested data
+- Consistent API across all network calls
+
+---
+
+### Form Submission
+
+**Traditional (Flaky):**
+```typescript
+test('form submission', async ({ page }) => {
+  await page.fill('#email', 'test@example.com');
+  await page.click('button[type="submit"]');
+  await page.waitForTimeout(3000);  // ❌ Hope it's enough
+  await expect(page.locator('.success')).toBeVisible();
+});
+```
+
+**Network-First (Deterministic):**
+```typescript
+test('form submission', async ({ page }) => {
+  const submitPromise = page.waitForResponse(
+    resp => resp.url().includes('/api/submit') &&
+            resp.request().method() === 'POST' &&
+            resp.ok()
+  );
+
+  await page.fill('#email', 'test@example.com');
+  await page.click('button[type="submit"]');
+
+  const response = await submitPromise;
+  const result = await response.json();
+
+  expect(result.success).toBe(true);
+  await expect(page.locator('.success')).toBeVisible();
+});
+```
+
+**With Playwright Utils:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+
+test('form submission', async ({ page, interceptNetworkCall }) => {
+  const submitCall = interceptNetworkCall({
+    method: 'POST',
+    url: '**/api/submit'
+  });
+
+  await page.getByLabel('Email').fill('test@example.com');
+  await page.getByRole('button', { name: 'Submit' }).click();
+
+  const { status, responseJson: result } = await submitCall;
+
+  // Automatic JSON parsing, no manual await
+  expect(status).toBe(200);
+  expect(result.success).toBe(true);
+  await expect(page.locator('.success')).toBeVisible();
+});
+```
+
+**Progression:**
+- Traditional: Hard waits (flaky)
+- Network-First (Vanilla): waitForResponse (deterministic)
+- Network-First (PW-Utils): interceptNetworkCall (deterministic + cleaner API)
+
+---
+
+## Common Misconceptions
+
+### "I Already Use waitForSelector"
+
+```typescript
+// This is still a hard wait in disguise
+await page.click('button');
+await page.waitForSelector('.success', { timeout: 5000 });
+```
+
+**Problem:** Waiting for DOM, not for the API that caused DOM change.
+
+**Better:**
+```typescript
+await page.waitForResponse(matcher);  // Wait for root cause
+await page.waitForSelector('.success');  // Then validate UI
+```
+
+### "My Tests Are Fast, Why Add Complexity?"
+
+**Short-term:** Tests are fast locally
+
+**Long-term problems:**
+- Different environments (CI slower)
+- Under load (API slower)
+- Network variability (random)
+- Scaling test suite (100 → 1000 tests)
+
+**Network-first prevents these issues before they appear.**
+
+### "Too Much Boilerplate"
+
+**Problem:** `waitForResponse` is verbose, repeated in every test.
+
+**Solution:** Use Playwright Utils `interceptNetworkCall` - built-in fixture that reduces boilerplate.
+
+**Vanilla Playwright (Repetitive):**
+```typescript
+test('test 1', async ({ page }) => {
+  const promise = page.waitForResponse(
+    resp => resp.url().includes('/api/submit') && resp.ok()
+  );
+  await page.click('button');
+  await promise;
+});
+
+test('test 2', async ({ page }) => {
+  const promise = page.waitForResponse(
+    resp => resp.url().includes('/api/load') && resp.ok()
+  );
+  await page.click('button');
+  await promise;
+});
+// Repeated pattern in every test
+```
+
+**With Playwright Utils (Cleaner):**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+
+test('test 1', async ({ page, interceptNetworkCall }) => {
+  const submitCall = interceptNetworkCall({ url: '**/api/submit' });
+  await page.click('button');
+  const { status, responseJson } = await submitCall;
+  expect(status).toBe(200);
+});
+
+test('test 2', async ({ page, interceptNetworkCall }) => {
+  const loadCall = interceptNetworkCall({ url: '**/api/load' });
+  await page.click('button');
+  const { responseJson } = await loadCall;
+  // Automatic JSON parsing, cleaner API
+});
+```
+
+**Benefits:**
+- Less boilerplate (fixture handles complexity)
+- Automatic JSON parsing
+- Glob pattern matching (`**/api/**`)
+- Consistent API across all tests
+
+See [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md#intercept-network-call) for setup.
+
+## Technical Implementation
+
+For detailed network-first patterns, see the knowledge base:
+- [Knowledge Base Index - Network & Reliability](/docs/reference/tea/knowledge-base.md)
+- [Complete Knowledge Base Index](/docs/reference/tea/knowledge-base.md)
+
+## Related Concepts
+
+**Core TEA Concepts:**
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - Determinism requires network-first
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - High-risk features need reliable tests
+
+**Technical Patterns:**
+- [Fixture Architecture](/docs/explanation/tea/fixture-architecture.md) - Network utilities as fixtures
+- [Knowledge Base System](/docs/explanation/tea/knowledge-base-system.md) - Network patterns in knowledge base
+
+**Overview:**
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Network-first in workflows
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - Why flakiness matters
+
+## Practical Guides
+
+**Workflow Guides:**
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md) - Review for hard waits
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md) - Generate network-first tests
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md) - Expand with network patterns
+
+**Use-Case Guides:**
+- [Using TEA with Existing Tests](/docs/how-to/brownfield/use-tea-with-existing-tests.md) - Fix flaky legacy tests
+
+**Customization:**
+- [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) - Network utilities (recorder, interceptor, error monitor)
+
+## Reference
+
+- [TEA Command Reference](/docs/reference/tea/commands.md) - All workflows use network-first
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - Network-first fragment
+- [Glossary](/docs/reference/glossary/index.md#test-architect-tea-concepts) - Network-first pattern term
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/explanation/tea/risk-based-testing.md

@@ -0,0 +1,586 @@
+---
+title: "Risk-Based Testing Explained"
+description: Understanding how TEA uses probability × impact scoring to prioritize testing effort
+---
+
+# Risk-Based Testing Explained
+
+Risk-based testing is TEA's core principle: testing depth scales with business impact. Instead of testing everything equally, focus effort where failures hurt most.
+
+## Overview
+
+Traditional testing approaches treat all features equally:
+- Every feature gets same test coverage
+- Same level of scrutiny regardless of impact
+- No systematic prioritization
+- Testing becomes checkbox exercise
+
+**Risk-based testing asks:**
+- What's the probability this will fail?
+- What's the impact if it does fail?
+- How much testing is appropriate for this risk level?
+
+**Result:** Testing effort matches business criticality.
+
+## The Problem
+
+### Equal Testing for Unequal Risk
+
+```markdown
+Feature A: User login (critical path, millions of users)
+Feature B: Export to PDF (nice-to-have, rarely used)
+
+Traditional approach:
+- Both get 10 tests
+- Both get same review scrutiny
+- Both take same development time
+
+Problem: Wasting effort on low-impact features while under-testing critical paths.
+```
+
+### No Objective Prioritization
+
+```markdown
+PM: "We need more tests for checkout"
+QA: "How many tests?"
+PM: "I don't know... a lot?"
+QA: "How do we know when we have enough?"
+PM: "When it feels safe?"
+
+Problem: Subjective decisions, no data, political debates.
+```
+
+## The Solution: Probability × Impact Scoring
+
+### Risk Score = Probability × Impact
+
+**Probability** (How likely to fail?)
+- **1 (Low):** Stable, well-tested, simple logic
+- **2 (Medium):** Moderate complexity, some unknowns
+- **3 (High):** Complex, untested, many edge cases
+
+**Impact** (How bad if it fails?)
+- **1 (Low):** Minor inconvenience, few users affected
+- **2 (Medium):** Degraded experience, workarounds exist
+- **3 (High):** Critical path broken, business impact
+
+**Score Range:** 1-9
+
+#### Risk Scoring Matrix
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': { 'fontSize':'14px'}}}%%
+graph TD
+    subgraph Matrix[" "]
+        direction TB
+        subgraph Impact3["Impact: HIGH (3)"]
+            P1I3["Score: 3<br/>Low Risk"]
+            P2I3["Score: 6<br/>HIGH RISK<br/>Mitigation Required"]
+            P3I3["Score: 9<br/>CRITICAL<br/>Blocks Release"]
+        end
+        subgraph Impact2["Impact: MEDIUM (2)"]
+            P1I2["Score: 2<br/>Low Risk"]
+            P2I2["Score: 4<br/>Medium Risk"]
+            P3I2["Score: 6<br/>HIGH RISK<br/>Mitigation Required"]
+        end
+        subgraph Impact1["Impact: LOW (1)"]
+            P1I1["Score: 1<br/>Low Risk"]
+            P2I1["Score: 2<br/>Low Risk"]
+            P3I1["Score: 3<br/>Low Risk"]
+        end
+    end
+
+    Prob1["Probability: LOW (1)"] -.-> P1I1
+    Prob1 -.-> P1I2
+    Prob1 -.-> P1I3
+
+    Prob2["Probability: MEDIUM (2)"] -.-> P2I1
+    Prob2 -.-> P2I2
+    Prob2 -.-> P2I3
+
+    Prob3["Probability: HIGH (3)"] -.-> P3I1
+    Prob3 -.-> P3I2
+    Prob3 -.-> P3I3
+
+    style P3I3 fill:#f44336,stroke:#b71c1c,stroke-width:3px,color:#fff
+    style P2I3 fill:#ff9800,stroke:#e65100,stroke-width:2px,color:#000
+    style P3I2 fill:#ff9800,stroke:#e65100,stroke-width:2px,color:#000
+    style P2I2 fill:#fff9c4,stroke:#f57f17,stroke-width:1px,color:#000
+    style P1I1 fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px,color:#000
+    style P2I1 fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px,color:#000
+    style P3I1 fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px,color:#000
+    style P1I2 fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px,color:#000
+    style P1I3 fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px,color:#000
+```
+
+**Legend:**
+- 🔴 Red (Score 9): CRITICAL - Blocks release
+- 🟠 Orange (Score 6-8): HIGH RISK - Mitigation required
+- 🟡 Yellow (Score 4-5): MEDIUM - Mitigation recommended
+- 🟢 Green (Score 1-3): LOW - Optional mitigation
+
+### Scoring Examples
+
+**Score 9 (Critical):**
+```
+Feature: Payment processing
+Probability: 3 (complex third-party integration)
+Impact: 3 (broken payments = lost revenue)
+Score: 3 × 3 = 9
+
+Action: Extensive testing required
+- E2E tests for all payment flows
+- API tests for all payment scenarios
+- Error handling for all failure modes
+- Security testing for payment data
+- Load testing for high traffic
+- Monitoring and alerts
+```
+
+**Score 1 (Low):**
+```
+Feature: Change profile theme color
+Probability: 1 (simple UI toggle)
+Impact: 1 (cosmetic only)
+Score: 1 × 1 = 1
+
+Action: Minimal testing
+- One E2E smoke test
+- Skip edge cases
+- No API tests needed
+```
+
+**Score 6 (Medium-High):**
+```
+Feature: User profile editing
+Probability: 2 (moderate complexity)
+Impact: 3 (users can't update info)
+Score: 2 × 3 = 6
+
+Action: Focused testing
+- E2E test for happy path
+- API tests for CRUD operations
+- Validation testing
+- Skip low-value edge cases
+```
+
+## How It Works in TEA
+
+### 1. Risk Categories
+
+TEA assesses risk across 6 categories:
+
+**TECH** - Technical debt, architecture fragility
+```
+Example: Migrating from REST to GraphQL
+Probability: 3 (major architectural change)
+Impact: 3 (affects all API consumers)
+Score: 9 - Extensive integration testing required
+```
+
+**SEC** - Security vulnerabilities
+```
+Example: Adding OAuth integration
+Probability: 2 (third-party dependency)
+Impact: 3 (auth breach = data exposure)
+Score: 6 - Security testing mandatory
+```
+
+**PERF** - Performance degradation
+```
+Example: Adding real-time notifications
+Probability: 2 (WebSocket complexity)
+Impact: 2 (slower experience)
+Score: 4 - Load testing recommended
+```
+
+**DATA** - Data integrity, corruption
+```
+Example: Database migration
+Probability: 2 (schema changes)
+Impact: 3 (data loss unacceptable)
+Score: 6 - Data validation tests required
+```
+
+**BUS** - Business logic errors
+```
+Example: Discount calculation
+Probability: 2 (business rules complex)
+Impact: 3 (wrong prices = revenue loss)
+Score: 6 - Business logic tests mandatory
+```
+
+**OPS** - Operational issues
+```
+Example: Logging system update
+Probability: 1 (straightforward)
+Impact: 2 (debugging harder without logs)
+Score: 2 - Basic smoke test sufficient
+```
+
+### 2. Test Priorities (P0-P3)
+
+Risk scores inform test priorities (but aren't the only factor):
+
+**P0 - Critical Path**
+- **Risk Scores:** Typically 6-9 (high risk)
+- **Other Factors:** Revenue impact, security-critical, regulatory compliance, frequent usage
+- **Coverage Target:** 100%
+- **Test Levels:** E2E + API
+- **Example:** Login, checkout, payment processing
+
+**P1 - High Value**
+- **Risk Scores:** Typically 4-6 (medium-high risk)
+- **Other Factors:** Core user journeys, complex logic, integration points
+- **Coverage Target:** 90%
+- **Test Levels:** API + selective E2E
+- **Example:** Profile editing, search, filters
+
+**P2 - Medium Value**
+- **Risk Scores:** Typically 2-4 (medium risk)
+- **Other Factors:** Secondary features, admin functionality, reporting
+- **Coverage Target:** 50%
+- **Test Levels:** API happy path only
+- **Example:** Export features, advanced settings
+
+**P3 - Low Value**
+- **Risk Scores:** Typically 1-2 (low risk)
+- **Other Factors:** Rarely used, nice-to-have, cosmetic
+- **Coverage Target:** 20% (smoke test)
+- **Test Levels:** E2E smoke test only
+- **Example:** Theme customization, experimental features
+
+**Note:** Priorities consider risk scores plus business context (usage frequency, user impact, etc.). See [Test Priorities Matrix](/docs/reference/tea/knowledge-base.md#quality-standards) for complete criteria.
+
+### 3. Mitigation Plans
+
+**Scores ≥6 require documented mitigation:**
+
+```markdown
+## Risk Mitigation
+
+**Risk:** Payment integration failure (Score: 9)
+
+**Mitigation Plan:**
+- Create comprehensive test suite (20+ tests)
+- Add payment sandbox environment
+- Implement retry logic with idempotency
+- Add monitoring and alerts
+- Document rollback procedure
+
+**Owner:** Backend team lead
+**Deadline:** Before production deployment
+**Status:** In progress
+```
+
+**Gate Rules:**
+- **Score = 9** (Critical): Mandatory FAIL - blocks release without mitigation
+- **Score 6-8** (High): Requires mitigation plan, becomes CONCERNS if incomplete
+- **Score 4-5** (Medium): Mitigation recommended but not required
+- **Score 1-3** (Low): No mitigation needed
+
+## Comparison: Traditional vs Risk-Based
+
+### Traditional Approach
+
+```typescript
+// Test everything equally
+describe('User profile', () => {
+  test('should display name');
+  test('should display email');
+  test('should display phone');
+  test('should display address');
+  test('should display bio');
+  test('should display avatar');
+  test('should display join date');
+  test('should display last login');
+  test('should display theme preference');
+  test('should display language preference');
+  // 10 tests for profile display (all equal priority)
+});
+```
+
+**Problems:**
+- Same effort for critical (name) vs trivial (theme)
+- No guidance on what matters
+- Wastes time on low-value tests
+
+### Risk-Based Approach
+
+```typescript
+// Test based on risk
+
+describe('User profile - Critical (P0)', () => {
+  test('should display name and email');  // Score: 9 (identity critical)
+  test('should allow editing name and email');
+  test('should validate email format');
+  test('should prevent unauthorized edits');
+  // 4 focused tests on high-risk areas
+});
+
+describe('User profile - High Value (P1)', () => {
+  test('should upload avatar');  // Score: 6 (users care about this)
+  test('should update bio');
+  // 2 tests for high-value features
+});
+
+// P2: Theme preference - single smoke test
+// P3: Last login display - skip (read-only, low value)
+```
+
+**Benefits:**
+- 6 focused tests vs 10 unfocused tests
+- Effort matches business impact
+- Clear priorities guide development
+- No wasted effort on trivial features
+
+## When to Use Risk-Based Testing
+
+### Always Use For:
+
+**Enterprise projects:**
+- High stakes (revenue, compliance, security)
+- Many features competing for test effort
+- Need objective prioritization
+
+**Large codebases:**
+- Can't test everything exhaustively
+- Need to focus limited QA resources
+- Want data-driven decisions
+
+**Regulated industries:**
+- Must justify testing decisions
+- Auditors want risk assessments
+- Compliance requires evidence
+
+### Consider Skipping For:
+
+**Tiny projects:**
+- 5 features total
+- Can test everything thoroughly
+- Risk scoring is overhead
+
+**Prototypes:**
+- Throw-away code
+- Speed over quality
+- Learning experiments
+
+## Real-World Example
+
+### Scenario: E-Commerce Checkout Redesign
+
+**Feature:** Redesigning checkout flow from 5 steps to 3 steps
+
+**Risk Assessment:**
+
+| Component | Probability | Impact | Score | Priority | Testing |
+|-----------|-------------|--------|-------|----------|---------|
+| **Payment processing** | 3 | 3 | 9 | P0 | 15 E2E + 20 API tests |
+| **Order validation** | 2 | 3 | 6 | P1 | 5 E2E + 10 API tests |
+| **Shipping calculation** | 2 | 2 | 4 | P1 | 3 E2E + 8 API tests |
+| **Promo code validation** | 2 | 2 | 4 | P1 | 2 E2E + 5 API tests |
+| **Gift message** | 1 | 1 | 1 | P3 | 1 E2E smoke test |
+
+**Test Budget:** 40 hours
+
+**Allocation:**
+- Payment (Score 9): 20 hours (50%)
+- Order validation (Score 6): 8 hours (20%)
+- Shipping (Score 4): 6 hours (15%)
+- Promo codes (Score 4): 4 hours (10%)
+- Gift message (Score 1): 2 hours (5%)
+
+**Result:** 50% of effort on highest-risk feature (payment), proportional allocation for others.
+
+### Without Risk-Based Testing:
+
+**Equal allocation:** 8 hours per component = wasted effort on gift message, under-testing payment.
+
+**Result:** Payment bugs slip through (critical), perfect testing of gift message (trivial).
+
+## Mitigation Strategies by Risk Level
+
+### Score 9: Mandatory Mitigation (Blocks Release)
+
+```markdown
+**Gate Impact:** FAIL - Cannot deploy without mitigation
+
+**Actions:**
+- Comprehensive test suite (E2E, API, security)
+- Multiple test environments (dev, staging, prod-mirror)
+- Load testing and performance validation
+- Security audit and penetration testing
+- Monitoring and alerting
+- Rollback plan documented
+- On-call rotation assigned
+
+**Cannot deploy until score is mitigated below 9.**
+```
+
+### Score 6-8: Required Mitigation (Gate: CONCERNS)
+
+```markdown
+**Gate Impact:** CONCERNS - Can deploy with documented mitigation plan
+
+**Actions:**
+- Targeted test suite (happy path + critical errors)
+- Test environment setup
+- Monitoring plan
+- Document mitigation and owners
+
+**Can deploy with approved mitigation plan.**
+```
+
+### Score 4-5: Recommended Mitigation
+
+```markdown
+**Gate Impact:** Advisory - Does not affect gate decision
+
+**Actions:**
+- Basic test coverage
+- Standard monitoring
+- Document known limitations
+
+**Can deploy, mitigation recommended but not required.**
+```
+
+### Score 1-3: Optional Mitigation
+
+```markdown
+**Gate Impact:** None
+
+**Actions:**
+- Smoke test if desired
+- Feature flag for easy disable (optional)
+
+**Can deploy without mitigation.**
+```
+
+## Technical Implementation
+
+For detailed risk governance patterns, see the knowledge base:
+- [Knowledge Base Index - Risk & Gates](/docs/reference/tea/knowledge-base.md)
+- [TEA Command Reference - *test-design](/docs/reference/tea/commands.md#test-design)
+
+### Risk Scoring Matrix
+
+TEA uses this framework in `*test-design`:
+
+```
+           Impact
+           1    2    3
+      ┌────┬────┬────┐
+    1 │ 1  │ 2  │ 3  │ Low risk
+P   2 │ 2  │ 4  │ 6  │ Medium risk
+r   3 │ 3  │ 6  │ 9  │ High risk
+o     └────┴────┴────┘
+b      Low  Med  High
+```
+
+### Gate Decision Rules
+
+| Score | Mitigation Required | Gate Impact |
+|-------|-------------------|-------------|
+| **9** | Mandatory, blocks release | FAIL if no mitigation |
+| **6-8** | Required, documented plan | CONCERNS if incomplete |
+| **4-5** | Recommended | Advisory only |
+| **1-3** | Optional | No impact |
+
+#### Gate Decision Flow
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': { 'fontSize':'14px'}}}%%
+flowchart TD
+    Start([Risk Assessment]) --> Score{Risk Score?}
+
+    Score -->|Score = 9| Critical[CRITICAL RISK<br/>Score: 9]
+    Score -->|Score 6-8| High[HIGH RISK<br/>Score: 6-8]
+    Score -->|Score 4-5| Medium[MEDIUM RISK<br/>Score: 4-5]
+    Score -->|Score 1-3| Low[LOW RISK<br/>Score: 1-3]
+
+    Critical --> HasMit9{Mitigation<br/>Plan?}
+    HasMit9 -->|Yes| Concerns9[CONCERNS ⚠️<br/>Can deploy with plan]
+    HasMit9 -->|No| Fail[FAIL ❌<br/>Blocks release]
+
+    High --> HasMit6{Mitigation<br/>Plan?}
+    HasMit6 -->|Yes| Pass6[PASS ✅<br/>or CONCERNS ⚠️]
+    HasMit6 -->|No| Concerns6[CONCERNS ⚠️<br/>Document plan needed]
+
+    Medium --> Advisory[Advisory Only<br/>No gate impact]
+    Low --> NoAction[No Action<br/>Proceed]
+
+    style Critical fill:#f44336,stroke:#b71c1c,stroke-width:3px,color:#fff
+    style Fail fill:#d32f2f,stroke:#b71c1c,stroke-width:3px,color:#fff
+    style High fill:#ff9800,stroke:#e65100,stroke-width:2px,color:#000
+    style Concerns9 fill:#ffc107,stroke:#f57f17,stroke-width:2px,color:#000
+    style Concerns6 fill:#ffc107,stroke:#f57f17,stroke-width:2px,color:#000
+    style Pass6 fill:#4caf50,stroke:#1b5e20,stroke-width:2px,color:#fff
+    style Medium fill:#fff9c4,stroke:#f57f17,stroke-width:1px,color:#000
+    style Low fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px,color:#000
+    style Advisory fill:#e8f5e9,stroke:#2e7d32,stroke-width:1px,color:#000
+    style NoAction fill:#e8f5e9,stroke:#2e7d32,stroke-width:1px,color:#000
+```
+
+## Common Misconceptions
+
+### "Risk-based = Less Testing"
+
+**Wrong:** Risk-based testing often means MORE testing where it matters.
+
+**Example:**
+- Traditional: 50 tests spread equally
+- Risk-based: 70 tests focused on P0/P1 (more total, better allocated)
+
+### "Low Priority = Skip Testing"
+
+**Wrong:** P3 still gets smoke tests.
+
+**Correct:**
+- P3: Smoke test (feature works at all)
+- P2: Happy path (feature works correctly)
+- P1: Happy path + errors
+- P0: Comprehensive (all scenarios)
+
+### "Risk Scores Are Permanent"
+
+**Wrong:** Risk changes over time.
+
+**Correct:**
+- Initial launch: Payment is Score 9 (untested integration)
+- After 6 months: Payment is Score 6 (proven in production)
+- Re-assess risk quarterly
+
+## Related Concepts
+
+**Core TEA Concepts:**
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - Quality complements risk assessment
+- [Engagement Models](/docs/explanation/tea/engagement-models.md) - When risk-based testing matters most
+- [Knowledge Base System](/docs/explanation/tea/knowledge-base-system.md) - How risk patterns are loaded
+
+**Technical Patterns:**
+- [Fixture Architecture](/docs/explanation/tea/fixture-architecture.md) - Building risk-appropriate test infrastructure
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Quality patterns for high-risk features
+
+**Overview:**
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Risk assessment in TEA lifecycle
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - Design philosophy
+
+## Practical Guides
+
+**Workflow Guides:**
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md) - Apply risk scoring
+- [How to Run Trace](/docs/how-to/workflows/run-trace.md) - Gate decisions based on risk
+- [How to Run NFR Assessment](/docs/how-to/workflows/run-nfr-assess.md) - NFR risk assessment
+
+**Use-Case Guides:**
+- [Running TEA for Enterprise](/docs/how-to/brownfield/use-tea-for-enterprise.md) - Enterprise risk management
+
+## Reference
+
+- [TEA Command Reference](/docs/reference/tea/commands.md) - `*test-design`, `*nfr-assess`, `*trace`
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - Risk governance fragments
+- [Glossary](/docs/reference/glossary/index.md#test-architect-tea-concepts) - Risk-based testing term
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/explanation/tea/test-quality-standards.md

@@ -0,0 +1,907 @@
+---
+title: "Test Quality Standards Explained"
+description: Understanding TEA's Definition of Done for deterministic, isolated, and maintainable tests
+---
+
+# Test Quality Standards Explained
+
+Test quality standards define what makes a test "good" in TEA. These aren't suggestions - they're the Definition of Done that prevents tests from rotting in review.
+
+## Overview
+
+**TEA's Quality Principles:**
+- **Deterministic** - Same result every run
+- **Isolated** - No dependencies on other tests
+- **Explicit** - Assertions visible in test body
+- **Focused** - Single responsibility, appropriate size
+- **Fast** - Execute in reasonable time
+
+**Why these matter:** Tests that violate these principles create maintenance burden, slow down development, and lose team trust.
+
+## The Problem
+
+### Tests That Rot in Review
+
+```typescript
+// ❌ The anti-pattern: This test will rot
+test('user can do stuff', async ({ page }) => {
+  await page.goto('/');
+  await page.waitForTimeout(5000);  // Non-deterministic
+
+  if (await page.locator('.banner').isVisible()) {  // Conditional
+    await page.click('.dismiss');
+  }
+
+  try {  // Try-catch for flow control
+    await page.click('#load-more');
+  } catch (e) {
+    // Silently continue
+  }
+
+  // ... 300 more lines of test logic
+  // ... no clear assertions
+});
+```
+
+**What's wrong:**
+- **Hard wait** - Flaky, wastes time
+- **Conditional** - Non-deterministic behavior
+- **Try-catch** - Hides failures
+- **Too large** - Hard to maintain
+- **Vague name** - Unclear purpose
+- **No explicit assertions** - What's being tested?
+
+**Result:** PR review comments: "This test is flaky, please fix" → never merged → test deleted → coverage lost
+
+### AI-Generated Tests Without Standards
+
+AI-generated tests without quality guardrails:
+
+```typescript
+// AI generates 50 tests like this:
+test('test1', async ({ page }) => {
+  await page.goto('/');
+  await page.waitForTimeout(3000);
+  // ... flaky, vague, redundant
+});
+
+test('test2', async ({ page }) => {
+  await page.goto('/');
+  await page.waitForTimeout(3000);
+  // ... duplicates test1
+});
+
+// ... 48 more similar tests
+```
+
+**Result:** 50 tests, 80% redundant, 90% flaky, 0% trusted by team - low-quality outputs that create maintenance burden.
+
+## The Solution: TEA's Quality Standards
+
+### 1. Determinism (No Flakiness)
+
+**Rule:** Test produces same result every run.
+
+**Requirements:**
+- ❌ No hard waits (`waitForTimeout`)
+- ❌ No conditionals for flow control (`if/else`)
+- ❌ No try-catch for flow control
+- ✅ Use network-first patterns (wait for responses)
+- ✅ Use explicit waits (waitForSelector, waitForResponse)
+
+**Bad Example:**
+```typescript
+test('flaky test', async ({ page }) => {
+  await page.click('button');
+  await page.waitForTimeout(2000);  // ❌ Might be too short
+
+  if (await page.locator('.modal').isVisible()) {  // ❌ Non-deterministic
+    await page.click('.dismiss');
+  }
+
+  try {  // ❌ Silently handles errors
+    await expect(page.locator('.success')).toBeVisible();
+  } catch (e) {
+    // Test passes even if assertion fails!
+  }
+});
+```
+
+**Good Example (Vanilla Playwright):**
+```typescript
+test('deterministic test', async ({ page }) => {
+  const responsePromise = page.waitForResponse(
+    resp => resp.url().includes('/api/submit') && resp.ok()
+  );
+
+  await page.click('button');
+  await responsePromise;  // ✅ Wait for actual response
+
+  // Modal should ALWAYS show (make it deterministic)
+  await expect(page.locator('.modal')).toBeVisible();
+  await page.click('.dismiss');
+
+  // Explicit assertion (fails if not visible)
+  await expect(page.locator('.success')).toBeVisible();
+});
+```
+
+**With Playwright Utils (Even Cleaner):**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+import { expect } from '@playwright/test';
+
+test('deterministic test', async ({ page, interceptNetworkCall }) => {
+  const submitCall = interceptNetworkCall({
+    method: 'POST',
+    url: '**/api/submit'
+  });
+
+  await page.click('button');
+
+  // Wait for actual response (automatic JSON parsing)
+  const { status, responseJson } = await submitCall;
+  expect(status).toBe(200);
+
+  // Modal should ALWAYS show (make it deterministic)
+  await expect(page.locator('.modal')).toBeVisible();
+  await page.click('.dismiss');
+
+  // Explicit assertion (fails if not visible)
+  await expect(page.locator('.success')).toBeVisible();
+});
+```
+
+**Why both work:**
+- Waits for actual event (network response)
+- No conditionals (behavior is deterministic)
+- Assertions fail loudly (no silent failures)
+- Same result every run (deterministic)
+
+**Playwright Utils additional benefits:**
+- Automatic JSON parsing
+- `{ status, responseJson }` structure (can validate response data)
+- No manual `await response.json()`
+
+### 2. Isolation (No Dependencies)
+
+**Rule:** Test runs independently, no shared state.
+
+**Requirements:**
+- ✅ Self-cleaning (cleanup after test)
+- ✅ No global state dependencies
+- ✅ Can run in parallel
+- ✅ Can run in any order
+- ✅ Use unique test data
+
+**Bad Example:**
+```typescript
+// ❌ Tests depend on execution order
+let userId: string;  // Shared global state
+
+test('create user', async ({ apiRequest }) => {
+  const { body } = await apiRequest({
+    method: 'POST',
+    path: '/api/users',
+    body: { email: 'test@example.com' }   (hard-coded)
+  });
+  userId = body.id;  // Store in global
+});
+
+test('update user', async ({ apiRequest }) => {
+  // Depends on previous test setting userId
+  await apiRequest({
+    method: 'PATCH',
+    path: `/api/users/${userId}`,
+    body: { name: 'Updated' }  
+  });
+  // No cleanup - leaves user in database
+});
+```
+
+**Problems:**
+- Tests must run in order (can't parallelize)
+- Second test fails if first skipped (`.only`)
+- Hard-coded data causes conflicts
+- No cleanup (database fills with test data)
+
+**Good Example (Vanilla Playwright):**
+```typescript
+test('should update user profile', async ({ request }) => {
+  // Create unique test data
+  const testEmail = `test-${Date.now()}@example.com`;
+
+  // Setup: Create user
+  const createResp = await request.post('/api/users', {
+    data: { email: testEmail, name: 'Original' }
+  });
+  const user = await createResp.json();
+
+  // Test: Update user
+  const updateResp = await request.patch(`/api/users/${user.id}`, {
+    data: { name: 'Updated' }
+  });
+  const updated = await updateResp.json();
+
+  expect(updated.name).toBe('Updated');
+
+  // Cleanup: Delete user
+  await request.delete(`/api/users/${user.id}`);
+});
+```
+
+**Even Better (With Playwright Utils):**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { expect } from '@playwright/test';
+import { faker } from '@faker-js/faker';
+
+test('should update user profile', async ({ apiRequest }) => {
+  // Dynamic unique test data
+  const testEmail = faker.internet.email();
+
+  // Setup: Create user
+  const { status: createStatus, body: user } = await apiRequest({
+    method: 'POST',
+    path: '/api/users',
+    body: { email: testEmail, name: faker.person.fullName() }  
+  });
+
+  expect(createStatus).toBe(201);
+
+  // Test: Update user
+  const { status, body: updated } = await apiRequest({
+    method: 'PATCH',
+    path: `/api/users/${user.id}`,
+    body: { name: 'Updated Name' }  
+  });
+
+  expect(status).toBe(200);
+  expect(updated.name).toBe('Updated Name');
+
+  // Cleanup: Delete user
+  await apiRequest({
+    method: 'DELETE',
+    path: `/api/users/${user.id}`
+  });
+});
+```
+
+**Playwright Utils Benefits:**
+- `{ status, body }` destructuring (cleaner than `response.status()` + `await response.json()`)
+- No manual `await response.json()`
+- Automatic retry for 5xx errors
+- Optional schema validation with `.validateSchema()`
+
+**Why it works:**
+- No global state
+- Unique test data (no conflicts)
+- Self-cleaning (deletes user)
+- Can run in parallel
+- Can run in any order
+
+### 3. Explicit Assertions (No Hidden Validation)
+
+**Rule:** Assertions visible in test body, not abstracted.
+
+**Requirements:**
+- ✅ Assertions in test code (not helper functions)
+- ✅ Specific assertions (not generic `toBeTruthy`)
+- ✅ Meaningful expectations (test actual behavior)
+
+**Bad Example:**
+```typescript
+// ❌ Assertions hidden in helper
+async function verifyProfilePage(page: Page) {
+  // Assertions buried in helper (not visible in test)
+  await expect(page.locator('h1')).toBeVisible();
+  await expect(page.locator('.email')).toContainText('@');
+  await expect(page.locator('.name')).not.toBeEmpty();
+}
+
+test('profile page', async ({ page }) => {
+  await page.goto('/profile');
+  await verifyProfilePage(page);  // What's being verified?
+});
+```
+
+**Problems:**
+- Can't see what's tested (need to read helper)
+- Hard to debug failures (which assertion failed?)
+- Reduces test readability
+- Hides important validation
+
+**Good Example:**
+```typescript
+// ✅ Assertions explicit in test
+test('should display profile with correct data', async ({ page }) => {
+  await page.goto('/profile');
+
+  // Explicit assertions - clear what's tested
+  await expect(page.locator('h1')).toContainText('Test User');
+  await expect(page.locator('.email')).toContainText('test@example.com');
+  await expect(page.locator('.bio')).toContainText('Software Engineer');
+  await expect(page.locator('img[alt="Avatar"]')).toBeVisible();
+});
+```
+
+**Why it works:**
+- See what's tested at a glance
+- Debug failures easily (know which assertion failed)
+- Test is self-documenting
+- No hidden behavior
+
+**Exception:** Use helper for setup/cleanup, not assertions.
+
+### 4. Focused Tests (Appropriate Size)
+
+**Rule:** Test has single responsibility, reasonable size.
+
+**Requirements:**
+- ✅ Test size < 300 lines
+- ✅ Single responsibility (test one thing well)
+- ✅ Clear describe/test names
+- ✅ Appropriate scope (not too granular, not too broad)
+
+**Bad Example:**
+```typescript
+// ❌ 500-line test testing everything
+test('complete user flow', async ({ page }) => {
+  // Registration (50 lines)
+  await page.goto('/register');
+  await page.fill('#email', 'test@example.com');
+  // ... 48 more lines
+
+  // Profile setup (100 lines)
+  await page.goto('/profile');
+  // ... 98 more lines
+
+  // Settings configuration (150 lines)
+  await page.goto('/settings');
+  // ... 148 more lines
+
+  // Data export (200 lines)
+  await page.goto('/export');
+  // ... 198 more lines
+
+  // Total: 500 lines, testing 4 different features
+});
+```
+
+**Problems:**
+- Failure in line 50 prevents testing lines 51-500
+- Hard to understand (what's being tested?)
+- Slow to execute (testing too much)
+- Hard to debug (which feature failed?)
+
+**Good Example:**
+```typescript
+// ✅ Focused tests - one responsibility each
+
+test('should register new user', async ({ page }) => {
+  await page.goto('/register');
+  await page.fill('#email', 'test@example.com');
+  await page.fill('#password', 'password123');
+  await page.click('button[type="submit"]');
+
+  await expect(page).toHaveURL('/welcome');
+  await expect(page.locator('h1')).toContainText('Welcome');
+});
+
+test('should configure user profile', async ({ page, authSession }) => {
+  await authSession.login({ email: 'test@example.com', password: 'pass' });
+  await page.goto('/profile');
+
+  await page.fill('#name', 'Test User');
+  await page.fill('#bio', 'Software Engineer');
+  await page.click('button:has-text("Save")');
+
+  await expect(page.locator('.success')).toBeVisible();
+});
+
+// ... separate tests for settings, export (each < 50 lines)
+```
+
+**Why it works:**
+- Each test has one responsibility
+- Failure is easy to diagnose
+- Can run tests independently
+- Test names describe exactly what's tested
+
+### 5. Fast Execution (Performance Budget)
+
+**Rule:** Individual test executes in < 1.5 minutes.
+
+**Requirements:**
+- ✅ Test execution < 90 seconds
+- ✅ Efficient selectors (getByRole > XPath)
+- ✅ Minimal redundant actions
+- ✅ Parallel execution enabled
+
+**Bad Example:**
+```typescript
+// ❌ Slow test (3+ minutes)
+test('slow test', async ({ page }) => {
+  await page.goto('/');
+  await page.waitForTimeout(10000);  // 10s wasted
+
+  // Navigate through 10 pages (2 minutes)
+  for (let i = 1; i <= 10; i++) {
+    await page.click(`a[href="/page-${i}"]`);
+    await page.waitForTimeout(5000);  // 5s per page = 50s wasted
+  }
+
+  // Complex XPath selector (slow)
+  await page.locator('//div[@class="container"]/section[3]/div[2]/p').click();
+
+  // More waiting
+  await page.waitForTimeout(30000);  // 30s wasted
+
+  await expect(page.locator('.result')).toBeVisible();
+});
+```
+
+**Total time:** 3+ minutes (95 seconds wasted on hard waits)
+
+**Good Example (Vanilla Playwright):**
+```typescript
+// ✅ Fast test (< 10 seconds)
+test('fast test', async ({ page }) => {
+  // Set up response wait
+  const apiPromise = page.waitForResponse(
+    resp => resp.url().includes('/api/result') && resp.ok()
+  );
+
+  await page.goto('/');
+
+  // Direct navigation (skip intermediate pages)
+  await page.goto('/page-10');
+
+  // Efficient selector
+  await page.getByRole('button', { name: 'Submit' }).click();
+
+  // Wait for actual response (fast when API is fast)
+  await apiPromise;
+
+  await expect(page.locator('.result')).toBeVisible();
+});
+```
+
+**With Playwright Utils:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+import { expect } from '@playwright/test';
+
+test('fast test', async ({ page, interceptNetworkCall }) => {
+  // Set up interception
+  const resultCall = interceptNetworkCall({
+    method: 'GET',
+    url: '**/api/result'
+  });
+
+  await page.goto('/');
+
+  // Direct navigation (skip intermediate pages)
+  await page.goto('/page-10');
+
+  // Efficient selector
+  await page.getByRole('button', { name: 'Submit' }).click();
+
+  // Wait for actual response (automatic JSON parsing)
+  const { status, responseJson } = await resultCall;
+
+  expect(status).toBe(200);
+  await expect(page.locator('.result')).toBeVisible();
+
+  // Can also validate response data if needed
+  // expect(responseJson.data).toBeDefined();
+});
+```
+
+**Total time:** < 10 seconds (no wasted waits)
+
+**Both examples achieve:**
+- No hard waits (wait for actual events)
+- Direct navigation (skip unnecessary steps)
+- Efficient selectors (getByRole)
+- Fast execution
+
+**Playwright Utils bonus:**
+- Can validate API response data easily
+- Automatic JSON parsing
+- Cleaner API
+
+## TEA's Quality Scoring
+
+TEA reviews tests against these standards in `*test-review`:
+
+### Scoring Categories (100 points total)
+
+**Determinism (35 points):**
+- No hard waits: 10 points
+- No conditionals: 10 points
+- No try-catch flow: 10 points
+- Network-first patterns: 5 points
+
+**Isolation (25 points):**
+- Self-cleaning: 15 points
+- No global state: 5 points
+- Parallel-safe: 5 points
+
+**Assertions (20 points):**
+- Explicit in test body: 10 points
+- Specific and meaningful: 10 points
+
+**Structure (10 points):**
+- Test size < 300 lines: 5 points
+- Clear naming: 5 points
+
+**Performance (10 points):**
+- Execution time < 1.5 min: 10 points
+
+#### Quality Scoring Breakdown
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': { 'fontSize':'14px'}}}%%
+pie title Test Quality Score (100 points)
+    "Determinism" : 35
+    "Isolation" : 25
+    "Assertions" : 20
+    "Structure" : 10
+    "Performance" : 10
+```
+
+```mermaid
+%%{init: {'theme':'base', 'themeVariables': { 'fontSize':'13px'}}}%%
+flowchart LR
+    subgraph Det[Determinism - 35 pts]
+        D1[No hard waits<br/>10 pts]
+        D2[No conditionals<br/>10 pts]
+        D3[No try-catch flow<br/>10 pts]
+        D4[Network-first<br/>5 pts]
+    end
+
+    subgraph Iso[Isolation - 25 pts]
+        I1[Self-cleaning<br/>15 pts]
+        I2[No global state<br/>5 pts]
+        I3[Parallel-safe<br/>5 pts]
+    end
+
+    subgraph Assrt[Assertions - 20 pts]
+        A1[Explicit in body<br/>10 pts]
+        A2[Specific/meaningful<br/>10 pts]
+    end
+
+    subgraph Struct[Structure - 10 pts]
+        S1[Size < 300 lines<br/>5 pts]
+        S2[Clear naming<br/>5 pts]
+    end
+
+    subgraph Perf[Performance - 10 pts]
+        P1[Time < 1.5 min<br/>10 pts]
+    end
+
+    Det --> Total([Total: 100 points])
+    Iso --> Total
+    Assrt --> Total
+    Struct --> Total
+    Perf --> Total
+
+    style Det fill:#ffebee,stroke:#c62828,stroke-width:2px
+    style Iso fill:#e3f2fd,stroke:#1565c0,stroke-width:2px
+    style Assrt fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px
+    style Struct fill:#fff9c4,stroke:#f57f17,stroke-width:2px
+    style Perf fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
+    style Total fill:#fff,stroke:#000,stroke-width:3px
+```
+
+### Score Interpretation
+
+| Score      | Interpretation | Action                                 |
+| ---------- | -------------- | -------------------------------------- |
+| **90-100** | Excellent      | Production-ready, minimal changes      |
+| **80-89**  | Good           | Minor improvements recommended         |
+| **70-79**  | Acceptable     | Address recommendations before release |
+| **60-69**  | Needs Work     | Fix critical issues                    |
+| **< 60**   | Critical       | Significant refactoring needed         |
+
+## Comparison: Good vs Bad Tests
+
+### Example: User Login
+
+**Bad Test (Score: 45/100):**
+```typescript
+test('login test', async ({ page }) => {  // Vague name
+  await page.goto('/login');
+  await page.waitForTimeout(3000);  // -10 (hard wait)
+
+  await page.fill('[name="email"]', 'test@example.com');
+  await page.fill('[name="password"]', 'password');
+
+  if (await page.locator('.remember-me').isVisible()) {  // -10 (conditional)
+    await page.click('.remember-me');
+  }
+
+  await page.click('button');
+
+  try {  // -10 (try-catch flow)
+    await page.waitForURL('/dashboard', { timeout: 5000 });
+  } catch (e) {
+    // Ignore navigation failure
+  }
+
+  // No assertions! -10
+  // No cleanup! -10
+});
+```
+
+**Issues:**
+- Determinism: 5/35 (hard wait, conditional, try-catch)
+- Isolation: 10/25 (no cleanup)
+- Assertions: 0/20 (no assertions!)
+- Structure: 15/10 (okay)
+- Performance: 5/10 (slow)
+- **Total: 45/100**
+
+**Good Test (Score: 95/100):**
+```typescript
+test('should login with valid credentials and redirect to dashboard', async ({ page, authSession }) => {
+  // Use fixture for deterministic auth
+  const loginPromise = page.waitForResponse(
+    resp => resp.url().includes('/api/auth/login') && resp.ok()
+  );
+
+  await page.goto('/login');
+  await page.getByLabel('Email').fill('test@example.com');
+  await page.getByLabel('Password').fill('password123');
+  await page.getByRole('button', { name: 'Sign in' }).click();
+
+  // Wait for actual API response
+  const response = await loginPromise;
+  const { token } = await response.json();
+
+  // Explicit assertions
+  expect(token).toBeDefined();
+  await expect(page).toHaveURL('/dashboard');
+  await expect(page.getByText('Welcome back')).toBeVisible();
+
+  // Cleanup handled by authSession fixture
+});
+```
+
+**Quality:**
+- Determinism: 35/35 (network-first, no conditionals)
+- Isolation: 25/25 (fixture handles cleanup)
+- Assertions: 20/20 (explicit and specific)
+- Structure: 10/10 (clear name, focused)
+- Performance: 5/10 (< 1 min)
+- **Total: 95/100**
+
+### Example: API Testing
+
+**Bad Test (Score: 50/100):**
+```typescript
+test('api test', async ({ request }) => {
+  const response = await request.post('/api/users', {
+    data: { email: 'test@example.com' }  // Hard-coded (conflicts)
+  });
+
+  if (response.ok()) {  // Conditional
+    const user = await response.json();
+    // Weak assertion
+    expect(user).toBeTruthy();
+  }
+
+  // No cleanup - user left in database
+});
+```
+
+**Good Test (Score: 92/100):**
+```typescript
+test('should create user with valid data', async ({ apiRequest }) => {
+  // Unique test data
+  const testEmail = `test-${Date.now()}@example.com`;
+
+  // Create user
+  const { status, body } = await apiRequest({
+    method: 'POST',
+    path: '/api/users',
+    body: { email: testEmail, name: 'Test User' }
+  });
+
+  // Explicit assertions
+  expect(status).toBe(201);
+  expect(body.id).toBeDefined();
+  expect(body.email).toBe(testEmail);
+  expect(body.name).toBe('Test User');
+
+  // Cleanup
+  await apiRequest({
+    method: 'DELETE',
+    path: `/api/users/${body.id}`
+  });
+});
+```
+
+## How TEA Enforces Standards
+
+### During Test Generation (`*atdd`, `*automate`)
+
+TEA generates tests following standards by default:
+
+```typescript
+// TEA-generated test (automatically follows standards)
+test('should submit contact form', async ({ page }) => {
+  // Network-first pattern (no hard waits)
+  const submitPromise = page.waitForResponse(
+    resp => resp.url().includes('/api/contact') && resp.ok()
+  );
+
+  // Accessible selectors (resilient)
+  await page.getByLabel('Name').fill('Test User');
+  await page.getByLabel('Email').fill('test@example.com');
+  await page.getByLabel('Message').fill('Test message');
+  await page.getByRole('button', { name: 'Send' }).click();
+
+  const response = await submitPromise;
+  const result = await response.json();
+
+  // Explicit assertions
+  expect(result.success).toBe(true);
+  await expect(page.getByText('Message sent')).toBeVisible();
+
+  // Size: 15 lines (< 300 ✓)
+  // Execution: ~2 seconds (< 90s ✓)
+});
+```
+
+### During Test Review (*test-review)
+
+TEA audits tests and flags violations:
+
+```markdown
+## Critical Issues
+
+### Hard Wait Detected (tests/login.spec.ts:23)
+**Issue:** `await page.waitForTimeout(3000)`
+**Score Impact:** -10 (Determinism)
+**Fix:** Use network-first pattern
+
+### Conditional Flow Control (tests/profile.spec.ts:45)
+**Issue:** `if (await page.locator('.banner').isVisible())`
+**Score Impact:** -10 (Determinism)
+**Fix:** Make banner presence deterministic
+
+## Recommendations
+
+### Extract Fixture (tests/auth.spec.ts)
+**Issue:** Login code repeated 5 times
+**Score Impact:** -3 (Structure)
+**Fix:** Extract to authSession fixture
+```
+
+## Definition of Done Checklist
+
+When is a test "done"?
+
+**Test Quality DoD:**
+- [ ] No hard waits (`waitForTimeout`)
+- [ ] No conditionals for flow control
+- [ ] No try-catch for flow control
+- [ ] Network-first patterns used
+- [ ] Assertions explicit in test body
+- [ ] Test size < 300 lines
+- [ ] Clear, descriptive test name
+- [ ] Self-cleaning (cleanup in afterEach or test)
+- [ ] Unique test data (no hard-coded values)
+- [ ] Execution time < 1.5 minutes
+- [ ] Can run in parallel
+- [ ] Can run in any order
+
+**Code Review DoD:**
+- [ ] Test quality score > 80
+- [ ] No critical issues from `*test-review`
+- [ ] Follows project patterns (fixtures, selectors)
+- [ ] Test reviewed by team member
+
+## Common Quality Issues
+
+### Issue: "My test needs conditionals for optional elements"
+
+**Wrong approach:**
+```typescript
+if (await page.locator('.banner').isVisible()) {
+  await page.click('.dismiss');
+}
+```
+
+**Right approach - Make it deterministic:**
+```typescript
+// Option 1: Always expect banner
+await expect(page.locator('.banner')).toBeVisible();
+await page.click('.dismiss');
+
+// Option 2: Test both scenarios separately
+test('should show banner for new users', ...);
+test('should not show banner for returning users', ...);
+```
+
+### Issue: "My test needs try-catch for error handling"
+
+**Wrong approach:**
+```typescript
+try {
+  await page.click('#optional-button');
+} catch (e) {
+  // Silently continue
+}
+```
+
+**Right approach - Make failures explicit:**
+```typescript
+// Option 1: Button should exist
+await page.click('#optional-button');  // Fails loudly if missing
+
+// Option 2: Button might not exist (test both)
+test('should work with optional button', async ({ page }) => {
+  const hasButton = await page.locator('#optional-button').count() > 0;
+  if (hasButton) {
+    await page.click('#optional-button');
+  }
+  // But now you're testing optional behavior explicitly
+});
+```
+
+### Issue: "Hard waits are easier than network patterns"
+
+**Short-term:** Hard waits seem simpler
+**Long-term:** Flaky tests waste more time than learning network patterns
+
+**Investment:**
+- 30 minutes to learn network-first patterns
+- Prevents hundreds of hours debugging flaky tests
+- Tests run faster (no wasted waits)
+- Team trusts test suite
+
+## Technical Implementation
+
+For detailed test quality patterns, see:
+- [Test Quality Fragment](/docs/reference/tea/knowledge-base.md#quality-standards)
+- [Test Levels Framework Fragment](/docs/reference/tea/knowledge-base.md#quality-standards)
+- [Complete Knowledge Base Index](/docs/reference/tea/knowledge-base.md)
+
+## Related Concepts
+
+**Core TEA Concepts:**
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Quality scales with risk
+- [Knowledge Base System](/docs/explanation/tea/knowledge-base-system.md) - How standards are enforced
+- [Engagement Models](/docs/explanation/tea/engagement-models.md) - Quality in different models
+
+**Technical Patterns:**
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Determinism explained
+- [Fixture Architecture](/docs/explanation/tea/fixture-architecture.md) - Isolation through fixtures
+
+**Overview:**
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Quality standards in lifecycle
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - Why quality matters
+
+## Practical Guides
+
+**Workflow Guides:**
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md) - Audit against these standards
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md) - Generate quality tests
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md) - Expand with quality
+
+**Use-Case Guides:**
+- [Using TEA with Existing Tests](/docs/how-to/brownfield/use-tea-with-existing-tests.md) - Improve legacy quality
+- [Running TEA for Enterprise](/docs/how-to/brownfield/use-tea-for-enterprise.md) - Enterprise quality thresholds
+
+## Reference
+
+- [TEA Command Reference](/docs/reference/tea/commands.md) - *test-review command
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - Test quality fragment
+- [Glossary](/docs/reference/glossary/index.md#test-architect-tea-concepts) - TEA terminology
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/brownfield/add-feature-to-existing.md

@@ -3,10 +3,7 @@ title: "How to Add a Feature to an Existing Project"
 description: How to add new features to an existing brownfield project
 ---
 
-
-Add new functionality to your brownfield codebase while respecting existing patterns and architecture.
-
----
+Use the `workflow-init` workflow to add new functionality to your brownfield codebase while respecting existing patterns and architecture.
 
 ## When to Use This
 
@@ -14,15 +11,11 @@ Add new functionality to your brownfield codebase while respecting existing patt
 - Major enhancements that need proper planning
 - Features that touch multiple parts of the system
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - Existing project documentation (run `document-project` first if needed)
 - Clear understanding of what you want to build
-
----
+:::
 
 ## Steps
 
@@ -73,19 +66,9 @@ Follow the standard Phase 4 implementation workflows:
 3. `dev-story` - Implement with tests
 4. `code-review` - Quality assurance
 
----
-
 ## Tips
 
 - Always ensure agents read your existing documentation
 - Pay attention to integration points with existing code
 - Follow existing conventions unless deliberately changing them
 - Document why you're adding new patterns (if any)
-
----
-
-## Related
-
-- [Brownfield Development Guide](/docs/how-to/brownfield/index.md)
-- [Document Existing Project](/docs/how-to/brownfield/document-existing-project.md)
-- [Quick Fix in Brownfield](/docs/how-to/brownfield/quick-fix-in-brownfield.md)

docs/how-to/brownfield/document-existing-project.md

@@ -3,11 +3,8 @@ title: "How to Document an Existing Project"
 description: How to document an existing brownfield codebase using BMad Method
 ---
 
-
 Use the `document-project` workflow to scan your entire codebase and generate comprehensive documentation about its current state.
 
----
-
 ## When to Use This
 
 - Starting work on an undocumented legacy project
@@ -15,14 +12,10 @@ Use the `document-project` workflow to scan your entire codebase and generate co
 - AI agents need context about existing code patterns
 - Onboarding new team members
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed in your project
 - Access to the codebase you want to document
-
----
+:::
 
 ## Steps
 
@@ -58,8 +51,6 @@ Review the documentation for:
 - Completeness of architecture description
 - Any missing business rules or intent
 
----
-
 ## What You Get
 
 - **Project overview** - High-level description of what the project does
@@ -68,17 +59,8 @@ Review the documentation for:
 - **Business rules** - Logic extracted from the codebase
 - **Integration points** - External APIs and services
 
----
-
 ## Tips
 
 - Run this before any major brownfield work
 - Keep the documentation updated as the project evolves
 - Use it as input for future PRD creation
-
----
-
-## Related
-
-- [Brownfield Development Guide](/docs/how-to/brownfield/index.md)
-- [Add Feature to Existing Project](/docs/how-to/brownfield/add-feature-to-existing.md)

docs/how-to/brownfield/index.md

@@ -3,24 +3,19 @@ title: "Brownfield Development"
 description: How to use BMad Method on existing codebases
 ---
 
-
-How to effectively use BMad Method when working on existing projects and legacy codebases.
+Use BMad Method effectively when working on existing projects and legacy codebases.
 
 ## What is Brownfield Development?
 
 **Brownfield** refers to working on existing projects with established codebases and patterns, as opposed to **greenfield** which means starting from scratch with a clean slate.
 
-This tutorial covers the essential workflow for onboarding to brownfield projects with BMad Method.
-
----
-
-## Prerequisites
+This guide covers the essential workflow for onboarding to brownfield projects with BMad Method.
 
+:::note[Prerequisites]
 - BMad Method installed (`npx bmad-method install`)
 - An existing codebase you want to work on
 - Access to an AI-powered IDE (Claude Code, Cursor, or Windsurf)
-
----
+:::
 
 ## Step 1: Clean Up Completed Planning Artifacts
 
@@ -30,8 +25,6 @@ If you have completed all PRD epics and stories through the BMad process, clean
 - `_bmad-output/planning-artifacts/`
 - `_bmad-output/implementation-artifacts/`
 
----
-
 ## Step 2: Maintain Quality Project Documentation
 
 Your `docs/` folder should contain succinct, well-organized documentation that accurately represents your project:
@@ -43,8 +36,6 @@ Your `docs/` folder should contain succinct, well-organized documentation that a
 
 For complex projects, consider using the `document-project` workflow. It offers runtime variants that will scan your entire project and document its actual current state.
 
----
-
 ## Step 3: Initialize for Brownfield Work
 
 Run `workflow-init`. It should recognize you are in an existing project. If not, explicitly clarify that this is brownfield development for a new feature.
@@ -85,18 +76,9 @@ When doing architecture, ensure the architect:
 
 Pay close attention here to prevent reinventing the wheel or making decisions that misalign with your existing architecture.
 
----
-
 ## Next Steps
 
 - **[Document Existing Project](/docs/how-to/brownfield/document-existing-project.md)** - How to document your brownfield codebase
 - **[Add Feature to Existing Project](/docs/how-to/brownfield/add-feature-to-existing.md)** - Adding new functionality
 - **[Quick Fix in Brownfield](/docs/how-to/brownfield/quick-fix-in-brownfield.md)** - Bug fixes and ad-hoc changes
 - **[Brownfield FAQ](/docs/explanation/faq/brownfield-faq.md)** - Common questions about brownfield development
-
----
-
-## Related Documentation
-
-- [Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md) - Getting started with BMM
-- [Quick Spec Flow](/docs/explanation/features/quick-flow.md) - Fast path for small changes

docs/how-to/brownfield/quick-fix-in-brownfield.md

@@ -3,10 +3,7 @@ title: "How to Make Quick Fixes in Brownfield Projects"
 description: How to make quick fixes and ad-hoc changes in brownfield projects
 ---
 
-
-Not everything requires the full BMad method or even Quick Flow. For bug fixes, refactorings, or small targeted changes, you can work directly with the agent.
-
----
+Use the **DEV agent** directly for bug fixes, refactorings, or small targeted changes that don't require the full BMad method or Quick Flow.
 
 ## When to Use This
 
@@ -16,8 +13,6 @@ Not everything requires the full BMad method or even Quick Flow. For bug fixes,
 - Learning about your codebase
 - One-off changes that don't need planning
 
----
-
 ## Steps
 
 ### 1. Load an Agent
@@ -54,8 +49,6 @@ The agent will:
 
 Review the changes made and commit when satisfied.
 
----
-
 ## Learning Your Codebase
 
 This approach is also excellent for exploring unfamiliar code:
@@ -74,8 +67,6 @@ LLMs are excellent at interpreting and analyzing code—whether it was AI-genera
 - Understand how things are built
 - Explore unfamiliar parts of the codebase
 
----
-
 ## When to Upgrade to Formal Planning
 
 Consider using Quick Flow or full BMad Method when:
@@ -84,11 +75,3 @@ Consider using Quick Flow or full BMad Method when:
 - You're unsure about the scope
 - The fix keeps growing in complexity
 - You need documentation for the change
-
----
-
-## Related
-
-- [Brownfield Development Guide](/docs/how-to/brownfield/index.md)
-- [Add Feature to Existing Project](/docs/how-to/brownfield/add-feature-to-existing.md)
-- [Quick Spec Flow](/docs/explanation/features/quick-flow.md)

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

@@ -0,0 +1,526 @@
+---
+title: "Running TEA for Enterprise Projects"
+description: Use TEA with compliance, security, and regulatory requirements in enterprise environments
+---
+
+# Running TEA for Enterprise Projects
+
+Use TEA on enterprise projects with compliance, security, audit, and regulatory requirements. This guide covers NFR assessment, audit trails, and evidence collection.
+
+## When to Use This
+
+- Enterprise track projects (not Quick Flow or simple BMad Method)
+- Compliance requirements (SOC 2, HIPAA, GDPR, etc.)
+- Security-critical applications (finance, healthcare, government)
+- Audit trail requirements
+- Strict NFR thresholds (performance, security, reliability)
+
+## Prerequisites
+
+- BMad Method installed (Enterprise track selected)
+- TEA agent available
+- Compliance requirements documented
+- Stakeholders identified (who approves gates)
+
+## Enterprise-Specific TEA Workflows
+
+### NFR Assessment (*nfr-assess)
+
+**Purpose:** Validate non-functional requirements with evidence.
+
+**When:** Phase 2 (early) and Release Gate
+
+**Why Enterprise Needs This:**
+- Compliance mandates specific thresholds
+- Audit trails required for certification
+- Security requirements are non-negotiable
+- Performance SLAs are contractual
+
+**Example:**
+```
+*nfr-assess
+
+Categories: Security, Performance, Reliability, Maintainability
+
+Security thresholds:
+- Zero critical vulnerabilities (required by SOC 2)
+- All endpoints require authentication
+- Data encrypted at rest (FIPS 140-2)
+- Audit logging on all data access
+
+Evidence:
+- Security scan: reports/nessus-scan.pdf
+- Penetration test: reports/pentest-2026-01.pdf
+- Compliance audit: reports/soc2-evidence.zip
+```
+
+**Output:** NFR assessment with PASS/CONCERNS/FAIL for each category.
+
+### Trace with Audit Evidence (*trace)
+
+**Purpose:** Requirements traceability with audit trail.
+
+**When:** Phase 2 (baseline), Phase 4 (refresh), Release Gate
+
+**Why Enterprise Needs This:**
+- Auditors require requirements-to-test mapping
+- Compliance certifications need traceability
+- Regulatory bodies want evidence
+
+**Example:**
+```
+*trace Phase 1
+
+Requirements: PRD.md (with compliance requirements)
+Test location: tests/
+
+Output: traceability-matrix.md with:
+- Requirement-to-test mapping
+- Compliance requirement coverage
+- Gap prioritization
+- Recommendations
+```
+
+**For Release Gate:**
+```
+*trace Phase 2
+
+Generate gate-decision-{gate_type}-{story_id}.md with:
+- Evidence references
+- Approver signatures
+- Compliance checklist
+- Decision rationale
+```
+
+### Test Design with Compliance Focus (*test-design)
+
+**Purpose:** Risk assessment with compliance and security focus.
+
+**When:** Phase 3 (system-level), Phase 4 (epic-level)
+
+**Why Enterprise Needs This:**
+- Security architecture alignment required
+- Compliance requirements must be testable
+- Performance requirements are contractual
+
+**Example:**
+```
+*test-design
+
+Mode: System-level
+
+Focus areas:
+- Security architecture (authentication, authorization, encryption)
+- 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
+- Audit logging validation
+```
+
+## Enterprise TEA Lifecycle
+
+### Phase 1: Discovery (Optional but Recommended)
+
+**Research compliance requirements:**
+```
+Analyst: *research
+
+Topics:
+- Industry compliance (SOC 2, HIPAA, GDPR)
+- Security standards (OWASP Top 10)
+- Performance benchmarks (industry P99)
+```
+
+### Phase 2: Planning (Required)
+
+**1. Define NFRs early:**
+```
+PM: *prd
+
+Include in PRD:
+- Security requirements (authentication, encryption)
+- Performance SLAs (response time, throughput)
+- Reliability targets (uptime, RTO, RPO)
+- Compliance mandates (data retention, audit logs)
+```
+
+**2. Assess NFRs:**
+```
+TEA: *nfr-assess
+
+Categories: All (Security, Performance, Reliability, Maintainability)
+
+Output: nfr-assessment.md
+- NFR requirements documented
+- Acceptance criteria defined
+- Test strategy planned
+```
+
+**3. Baseline (brownfield only):**
+```
+TEA: *trace Phase 1
+
+Establish baseline coverage before new work
+```
+
+### Phase 3: Solutioning (Required)
+
+**1. Architecture with testability review:**
+```
+Architect: *architecture
+
+TEA: *test-design (system-level)
+
+Focus:
+- Security architecture testability
+- Performance testing strategy
+- Compliance requirement mapping
+```
+
+**2. Test infrastructure:**
+```
+TEA: *framework
+
+Requirements:
+- Separate test environments (dev, staging, prod-mirror)
+- Secure test data handling (PHI, PII)
+- Audit logging in tests
+```
+
+**3. CI/CD with compliance:**
+```
+TEA: *ci
+
+Requirements:
+- Secrets management (Vault, AWS Secrets Manager)
+- Test isolation (no cross-contamination)
+- Artifact retention (compliance audit trail)
+- Access controls (who can run production tests)
+```
+
+### Phase 4: Implementation (Required)
+
+**Per epic:**
+```
+1. TEA: *test-design (epic-level)
+   Focus: Compliance, security, performance for THIS epic
+
+2. TEA: *atdd (optional)
+   Generate tests including security/compliance scenarios
+
+3. DEV: Implement story
+
+4. TEA: *automate
+   Expand coverage including compliance edge cases
+
+5. TEA: *test-review
+   Audit quality (score >80 per epic, rises to >85 at release)
+
+6. TEA: *trace Phase 1
+   Refresh coverage, verify compliance requirements tested
+```
+
+### Release Gate (Required)
+
+**1. Final NFR assessment:**
+```
+TEA: *nfr-assess
+
+All categories (if not done earlier)
+Latest evidence (performance tests, security scans)
+```
+
+**2. Final quality audit:**
+```
+TEA: *test-review tests/
+
+Full suite review
+Quality target: >85 for enterprise
+```
+
+**3. Gate decision:**
+```
+TEA: *trace Phase 2
+
+Evidence required:
+- traceability-matrix.md (from Phase 1)
+- test-review.md (from quality audit)
+- nfr-assessment.md (from NFR assessment)
+- Test execution results (must have test results available)
+
+Decision: PASS/CONCERNS/FAIL/WAIVED
+
+Archive all artifacts for compliance audit
+```
+
+**Note:** Phase 2 requires test execution results. If results aren't available, Phase 2 will be skipped.
+
+**4. Archive for audit:**
+```
+Archive:
+- All test results
+- Coverage reports
+- NFR assessments
+- Gate decisions
+- Approver signatures
+
+Retention: Per compliance requirements (7 years for HIPAA)
+```
+
+## Enterprise-Specific Requirements
+
+### Evidence Collection
+
+**Required artifacts:**
+- Requirements traceability matrix
+- Test execution results (with timestamps)
+- NFR assessment reports
+- Security scan results
+- Performance test results
+- Gate decision records
+- Approver signatures
+
+**Storage:**
+```
+compliance/
+├── 2026-Q1/
+│   ├── release-1.2.0/
+│   │   ├── traceability-matrix.md
+│   │   ├── test-review.md
+│   │   ├── nfr-assessment.md
+│   │   ├── gate-decision-release-v1.2.0.md
+│   │   ├── test-results/
+│   │   ├── security-scans/
+│   │   └── approvals.pdf
+```
+
+**Retention:** 7 years (HIPAA), 3 years (SOC 2), per your compliance needs
+
+### Approver Workflows
+
+**Multi-level approval required:**
+
+```markdown
+## Gate Approvals Required
+
+### Technical Approval
+- [ ] QA Lead - Test coverage adequate
+- [ ] Tech Lead - Technical quality acceptable
+- [ ] Security Lead - Security requirements met
+
+### Business Approval
+- [ ] Product Manager - Business requirements met
+- [ ] Compliance Officer - Regulatory requirements met
+
+### Executive Approval (for major releases)
+- [ ] VP Engineering - Overall quality acceptable
+- [ ] CTO - Architecture approved for production
+```
+
+### Compliance Checklists
+
+**SOC 2 Example:**
+```markdown
+## SOC 2 Compliance Checklist
+
+### Access Controls
+- [ ] All API endpoints require authentication
+- [ ] Authorization tested for all protected resources
+- [ ] Session management secure (token expiration tested)
+
+### Audit Logging
+- [ ] All data access logged
+- [ ] Logs immutable (append-only)
+- [ ] Log retention policy enforced
+
+### Data Protection
+- [ ] Data encrypted at rest (tested)
+- [ ] Data encrypted in transit (HTTPS enforced)
+- [ ] PII handling compliant (masking tested)
+
+### Testing Evidence
+- [ ] Test coverage >80% (verified)
+- [ ] Security tests passing (100%)
+- [ ] Traceability matrix complete
+```
+
+**HIPAA Example:**
+```markdown
+## HIPAA Compliance Checklist
+
+### PHI Protection
+- [ ] PHI encrypted at rest (AES-256)
+- [ ] PHI encrypted in transit (TLS 1.3)
+- [ ] PHI access logged (audit trail)
+
+### Access Controls
+- [ ] Role-based access control (RBAC tested)
+- [ ] Minimum necessary access (tested)
+- [ ] Authentication strong (MFA tested)
+
+### Breach Notification
+- [ ] Breach detection tested
+- [ ] Notification workflow tested
+- [ ] Incident response plan tested
+```
+
+## Enterprise Tips
+
+### Start with Security
+
+**Priority 1:** Security requirements
+```
+1. Document all security requirements
+2. Generate security tests with *atdd
+3. Run security test suite
+4. Pass security audit BEFORE moving forward
+```
+
+**Why:** Security failures block everything in enterprise.
+
+**Example: RBAC Testing**
+
+**Vanilla Playwright:**
+```typescript
+test('should enforce role-based access', async ({ request }) => {
+  // Login as regular user
+  const userResp = await request.post('/api/auth/login', {
+    data: { email: 'user@example.com', password: 'pass' }
+  });
+  const { token: userToken } = await userResp.json();
+
+  // Try to access admin endpoint
+  const adminResp = await request.get('/api/admin/users', {
+    headers: { Authorization: `Bearer ${userToken}` }
+  });
+
+  expect(adminResp.status()).toBe(403);  // Forbidden
+});
+```
+
+**With Playwright Utils (Cleaner, Reusable):**
+```typescript
+import { test as base, expect } from '@playwright/test';
+import { test as apiRequestFixture } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { createAuthFixtures } from '@seontechnologies/playwright-utils/auth-session';
+import { mergeTests } from '@playwright/test';
+
+const authFixtureTest = base.extend(createAuthFixtures());
+export const testWithAuth = mergeTests(apiRequestFixture, authFixtureTest);
+
+testWithAuth('should enforce role-based access', async ({ apiRequest, authToken }) => {
+  // Auth token from fixture (configured for 'user' role)
+  const { status } = await apiRequest({
+    method: 'GET',
+    path: '/api/admin/users',  // Admin endpoint
+    headers: { Authorization: `Bearer ${authToken}` }
+  });
+
+  expect(status).toBe(403);  // Regular user denied
+});
+
+testWithAuth('admin can access admin endpoint', async ({ apiRequest, authToken, authOptions }) => {
+  // Override to admin role
+  authOptions.userIdentifier = 'admin';
+
+  const { status, body } = await apiRequest({
+    method: 'GET',
+    path: '/api/admin/users',
+    headers: { Authorization: `Bearer ${authToken}` }
+  });
+
+  expect(status).toBe(200);  // Admin allowed
+  expect(body).toBeInstanceOf(Array);
+});
+```
+
+**Note:** Auth-session requires provider setup in global-setup.ts. See [auth-session configuration](https://seontechnologies.github.io/playwright-utils/auth-session.html).
+
+**Playwright Utils Benefits for Compliance:**
+- Multi-user auth testing (regular, admin, etc.)
+- Token persistence (faster test execution)
+- Consistent auth patterns (audit trail)
+- Automatic cleanup
+
+### Set Higher Quality Thresholds
+
+**Enterprise quality targets:**
+- Test coverage: >85% (vs 80% for non-enterprise)
+- Quality score: >85 (vs 75 for non-enterprise)
+- P0 coverage: 100% (non-negotiable)
+- P1 coverage: >95% (vs 90% for non-enterprise)
+
+**Rationale:** Enterprise systems affect more users, higher stakes.
+
+### Document Everything
+
+**Auditors need:**
+- Why decisions were made (rationale)
+- Who approved (signatures)
+- When (timestamps)
+- What evidence (test results, scan reports)
+
+**Use TEA's structured outputs:**
+- Reports have timestamps
+- Decisions have rationale
+- Evidence is referenced
+- Audit trail is automatic
+
+### Budget for Compliance Testing
+
+**Enterprise testing costs more:**
+- Penetration testing: $10k-50k
+- Security audits: $5k-20k
+- Performance testing tools: $500-5k/month
+- Compliance consulting: $200-500/hour
+
+**Plan accordingly:**
+- Budget in project cost
+- Schedule early (3+ months for SOC 2)
+- Don't skip (non-negotiable for compliance)
+
+### Use External Validators
+
+**Don't self-certify:**
+- Penetration testing: Hire external firm
+- Security audits: Independent auditor
+- Compliance: Certification body
+- Performance: Load testing service
+
+**TEA's role:** Prepare for external validation, don't replace it.
+
+## Related Guides
+
+**Workflow Guides:**
+- [How to Run NFR Assessment](/docs/how-to/workflows/run-nfr-assess.md) - Deep dive on NFRs
+- [How to Run Trace](/docs/how-to/workflows/run-trace.md) - Gate decisions with evidence
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md) - Quality audits
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md) - Compliance-focused planning
+
+**Use-Case Guides:**
+- [Using TEA with Existing Tests](/docs/how-to/brownfield/use-tea-with-existing-tests.md) - Brownfield patterns
+
+**Customization:**
+- [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) - Production-ready utilities
+
+## Understanding the Concepts
+
+- [Engagement Models](/docs/explanation/tea/engagement-models.md) - Enterprise model explained
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Probability × impact scoring
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - Enterprise quality thresholds
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Complete TEA lifecycle
+
+## Reference
+
+- [TEA Command Reference](/docs/reference/tea/commands.md) - All 8 workflows
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Enterprise config options
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - Testing patterns
+- [Glossary](/docs/reference/glossary/index.md#test-architect-tea-concepts) - TEA terminology
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/brownfield/use-tea-with-existing-tests.md

@@ -0,0 +1,577 @@
+---
+title: "Using TEA with Existing Tests (Brownfield)"
+description: Apply TEA workflows to legacy codebases with existing test suites
+---
+
+# Using TEA with Existing Tests (Brownfield)
+
+Use TEA on brownfield projects (existing codebases with legacy tests) to establish coverage baselines, identify gaps, and improve test quality without starting from scratch.
+
+## When to Use This
+
+- Existing codebase with some tests already written
+- Legacy test suite needs quality improvement
+- Adding features to existing application
+- Need to understand current test coverage
+- Want to prevent regression as you add features
+
+## Prerequisites
+
+- BMad Method installed
+- TEA agent available
+- Existing codebase with tests (even if incomplete or low quality)
+- Tests run successfully (or at least can be executed)
+
+**Note:** If your codebase is completely undocumented, run `*document-project` first to create baseline documentation.
+
+## Brownfield Strategy
+
+### Phase 1: Establish Baseline
+
+Understand what you have before changing anything.
+
+#### Step 1: Baseline Coverage with *trace
+
+Run `*trace` Phase 1 to map existing tests to requirements:
+
+```
+*trace
+```
+
+**Select:** Phase 1 (Requirements Traceability)
+
+**Provide:**
+- Existing requirements docs (PRD, user stories, feature specs)
+- Test location (`tests/` or wherever tests live)
+- Focus areas (specific features if large codebase)
+
+**Output:** `traceability-matrix.md` showing:
+- Which requirements have tests
+- Which requirements lack coverage
+- Coverage classification (FULL/PARTIAL/NONE)
+- Gap prioritization
+
+**Example Baseline:**
+```markdown
+# Baseline Coverage (Before Improvements)
+
+**Total Requirements:** 50
+**Full Coverage:** 15 (30%)
+**Partial Coverage:** 20 (40%)
+**No Coverage:** 15 (30%)
+
+**By Priority:**
+- P0: 50% coverage (5/10) ❌ Critical gap
+- P1: 40% coverage (8/20) ⚠️ Needs improvement
+- P2: 20% coverage (2/10) ✅ Acceptable
+```
+
+This baseline becomes your improvement target.
+
+#### Step 2: Quality Audit with *test-review
+
+Run `*test-review` on existing tests:
+
+```
+*test-review tests/
+```
+
+**Output:** `test-review.md` with quality score and issues.
+
+**Common Brownfield Issues:**
+- Hard waits everywhere (`page.waitForTimeout(5000)`)
+- Fragile CSS selectors (`.class > div:nth-child(3)`)
+- No test isolation (tests depend on execution order)
+- Try-catch for flow control
+- Tests don't clean up (leave test data in DB)
+
+**Example Baseline Quality:**
+```markdown
+# Quality Score: 55/100
+
+**Critical Issues:** 12
+- 8 hard waits
+- 4 conditional flow control
+
+**Recommendations:** 25
+- Extract fixtures
+- Improve selectors
+- Add network assertions
+```
+
+This shows where to focus improvement efforts.
+
+### Phase 2: Prioritize Improvements
+
+Don't try to fix everything at once.
+
+#### Focus on Critical Path First
+
+**Priority 1: P0 Requirements**
+```
+Goal: Get P0 coverage to 100%
+
+Actions:
+1. Identify P0 requirements with no tests (from trace)
+2. Run *automate to generate tests for missing P0 scenarios
+3. Fix critical quality issues in P0 tests (from test-review)
+```
+
+**Priority 2: Fix Flaky Tests**
+```
+Goal: Eliminate flakiness
+
+Actions:
+1. Identify tests with hard waits (from test-review)
+2. Replace with network-first patterns
+3. Run burn-in loops to verify stability
+```
+
+**Example Modernization:**
+
+**Before (Flaky - Hard Waits):**
+```typescript
+test('checkout completes', async ({ page }) => {
+  await page.click('button[name="checkout"]');
+  await page.waitForTimeout(5000);  // ❌ Flaky
+  await expect(page.locator('.confirmation')).toBeVisible();
+});
+```
+
+**After (Network-First - Vanilla):**
+```typescript
+test('checkout completes', async ({ page }) => {
+  const checkoutPromise = page.waitForResponse(
+    resp => resp.url().includes('/api/checkout') && resp.ok()
+  );
+  await page.click('button[name="checkout"]');
+  await checkoutPromise;  // ✅ Deterministic
+  await expect(page.locator('.confirmation')).toBeVisible();
+});
+```
+
+**After (With Playwright Utils - Cleaner API):**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+import { expect } from '@playwright/test';
+
+test('checkout completes', async ({ page, interceptNetworkCall }) => {
+  // Use interceptNetworkCall for cleaner network interception
+  const checkoutCall = interceptNetworkCall({
+    method: 'POST',
+    url: '**/api/checkout'
+  });
+
+  await page.click('button[name="checkout"]');
+
+  // Wait for response (automatic JSON parsing)
+  const { status, responseJson: order } = await checkoutCall;
+
+  // Validate API response
+  expect(status).toBe(200);
+  expect(order.status).toBe('confirmed');
+
+  // Validate UI
+  await expect(page.locator('.confirmation')).toBeVisible();
+});
+```
+
+**Playwright Utils Benefits:**
+- `interceptNetworkCall` for cleaner network interception
+- Automatic JSON parsing (`responseJson` ready to use)
+- No manual `await response.json()`
+- Glob pattern matching (`**/api/checkout`)
+- Cleaner, more maintainable code
+
+**For automatic error detection,** use `network-error-monitor` fixture separately. See [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md#network-error-monitor).
+
+**Priority 3: P1 Requirements**
+```
+Goal: Get P1 coverage to 80%+
+
+Actions:
+1. Generate tests for highest-risk P1 gaps
+2. Improve test quality incrementally
+```
+
+#### Create Improvement Roadmap
+
+```markdown
+# Test Improvement Roadmap
+
+## Week 1: Critical Path (P0)
+- [ ] Add 5 missing P0 tests (Epic 1: Auth)
+- [ ] Fix 8 hard waits in auth tests
+- [ ] Verify P0 coverage = 100%
+
+## Week 2: Flakiness
+- [ ] Replace all hard waits with network-first
+- [ ] Fix conditional flow control
+- [ ] Run burn-in loops (target: 0 failures in 10 runs)
+
+## Week 3: High-Value Coverage (P1)
+- [ ] Add 10 missing P1 tests
+- [ ] Improve selector resilience
+- [ ] P1 coverage target: 80%
+
+## Week 4: Quality Polish
+- [ ] Extract fixtures for common patterns
+- [ ] Add network assertions
+- [ ] Quality score target: 75+
+```
+
+### Phase 3: Incremental Improvement
+
+Apply TEA workflows to new work while improving legacy tests.
+
+#### For New Features (Greenfield Within Brownfield)
+
+**Use full TEA workflow:**
+```
+1. *test-design (epic-level) - Plan tests for new feature
+2. *atdd - Generate failing tests first (TDD)
+3. Implement feature
+4. *automate - Expand coverage
+5. *test-review - Ensure quality
+```
+
+**Benefits:**
+- New code has high-quality tests from day one
+- Gradually raises overall quality
+- Team learns good patterns
+
+#### For Bug Fixes (Regression Prevention)
+
+**Add regression tests:**
+```
+1. Reproduce bug with failing test
+2. Fix bug
+3. Verify test passes
+4. Run *test-review on regression test
+5. Add to regression test suite
+```
+
+#### For Refactoring (Regression Safety)
+
+**Before refactoring:**
+```
+1. Run *trace - Baseline coverage
+2. Note current coverage %
+3. Refactor code
+4. Run *trace - Verify coverage maintained
+5. No coverage should decrease
+```
+
+### Phase 4: Continuous Improvement
+
+Track improvement over time.
+
+#### Quarterly Quality Audits
+
+**Q1 Baseline:**
+```
+Coverage: 30%
+Quality Score: 55/100
+Flakiness: 15% fail rate
+```
+
+**Q2 Target:**
+```
+Coverage: 50% (focus on P0)
+Quality Score: 65/100
+Flakiness: 5%
+```
+
+**Q3 Target:**
+```
+Coverage: 70%
+Quality Score: 75/100
+Flakiness: 1%
+```
+
+**Q4 Target:**
+```
+Coverage: 85%
+Quality Score: 85/100
+Flakiness: <0.5%
+```
+
+## Brownfield-Specific Tips
+
+### Don't Rewrite Everything
+
+**Common mistake:**
+```
+"Our tests are bad, let's delete them all and start over!"
+```
+
+**Better approach:**
+```
+"Our tests are bad, let's:
+1. Keep tests that work (even if not perfect)
+2. Fix critical quality issues incrementally
+3. Add tests for gaps
+4. Gradually improve over time"
+```
+
+**Why:**
+- Rewriting is risky (might lose coverage)
+- Incremental improvement is safer
+- Team learns gradually
+- Business value delivered continuously
+
+### Use Regression Hotspots
+
+**Identify regression-prone areas:**
+```markdown
+## Regression Hotspots
+
+**Based on:**
+- Bug reports (last 6 months)
+- Customer complaints
+- Code complexity (cyclomatic complexity >10)
+- Frequent changes (git log analysis)
+
+**High-Risk Areas:**
+1. Authentication flow (12 bugs in 6 months)
+2. Checkout process (8 bugs)
+3. Payment integration (6 bugs)
+
+**Test Priority:**
+- Add regression tests for these areas FIRST
+- Ensure P0 coverage before touching code
+```
+
+### Quarantine Flaky Tests
+
+Don't let flaky tests block improvement:
+
+```typescript
+// Mark flaky tests with .skip temporarily
+test.skip('flaky test - needs fixing', async ({ page }) => {
+  // TODO: Fix hard wait on line 45
+  // TODO: Add network-first pattern
+});
+```
+
+**Track quarantined tests:**
+```markdown
+# Quarantined Tests
+
+| Test                | Reason                     | Owner    | Target Fix Date |
+| ------------------- | -------------------------- | -------- | --------------- |
+| checkout.spec.ts:45 | Hard wait causes flakiness | QA Team  | 2026-01-20      |
+| profile.spec.ts:28  | Conditional flow control   | Dev Team | 2026-01-25      |
+```
+
+**Fix systematically:**
+- Don't accumulate quarantined tests
+- Set deadlines for fixes
+- Review quarantine list weekly
+
+### Migrate One Directory at a Time
+
+**Large test suite?** Improve incrementally:
+
+**Week 1:** `tests/auth/`
+```
+1. Run *test-review on auth tests
+2. Fix critical issues
+3. Re-review
+4. Mark directory as "modernized"
+```
+
+**Week 2:** `tests/api/`
+```
+Same process
+```
+
+**Week 3:** `tests/e2e/`
+```
+Same process
+```
+
+**Benefits:**
+- Focused improvement
+- Visible progress
+- Team learns patterns
+- Lower risk
+
+### Document Migration Status
+
+**Track which tests are modernized:**
+
+```markdown
+# Test Suite Status
+
+| Directory          | Tests | Quality Score | Status        | Notes          |
+| ------------------ | ----- | ------------- | ------------- | -------------- |
+| tests/auth/        | 15    | 85/100        | ✅ Modernized  | Week 1 cleanup |
+| tests/api/         | 32    | 78/100        | ⚠️ In Progress | Week 2         |
+| tests/e2e/         | 28    | 62/100        | ❌ Legacy      | Week 3 planned |
+| tests/integration/ | 12    | 45/100        | ❌ Legacy      | Week 4 planned |
+
+**Legend:**
+- ✅ Modernized: Quality >80, no critical issues
+- ⚠️ In Progress: Active improvement
+- ❌ Legacy: Not yet touched
+```
+
+## Common Brownfield Challenges
+
+### "We Don't Know What Tests Cover"
+
+**Problem:** No documentation, unclear what tests do.
+
+**Solution:**
+```
+1. Run *trace - TEA analyzes tests and maps to requirements
+2. Review traceability matrix
+3. Document findings
+4. Use as baseline for improvement
+```
+
+TEA reverse-engineers test coverage even without documentation.
+
+### "Tests Are Too Brittle to Touch"
+
+**Problem:** Afraid to modify tests (might break them).
+
+**Solution:**
+```
+1. Run tests, capture current behavior (baseline)
+2. Make small improvement (fix one hard wait)
+3. Run tests again
+4. If still pass, continue
+5. If fail, investigate why
+
+Incremental changes = lower risk
+```
+
+### "No One Knows How to Run Tests"
+
+**Problem:** Test documentation is outdated or missing.
+
+**Solution:**
+```
+1. Document manually or ask TEA to help analyze test structure
+2. Create tests/README.md with:
+   - How to install dependencies
+   - How to run tests (npx playwright test, npm test, etc.)
+   - What each test directory contains
+   - Common issues and troubleshooting
+3. Commit documentation for team
+```
+
+**Note:** `*framework` is for new test setup, not existing tests. For brownfield, document what you have.
+
+### "Tests Take Hours to Run"
+
+**Problem:** Full test suite takes 4+ hours.
+
+**Solution:**
+```
+1. Configure parallel execution (shard tests across workers)
+2. Add selective testing (run only affected tests on PR)
+3. Run full suite nightly only
+4. Optimize slow tests (remove hard waits, improve selectors)
+
+Before: 4 hours sequential
+After: 15 minutes with sharding + selective testing
+```
+
+**How `*ci` helps:**
+- Scaffolds CI configuration with parallel sharding examples
+- Provides selective testing script templates
+- Documents burn-in and optimization strategies
+- But YOU configure workers, test selection, and optimization
+
+**With Playwright Utils burn-in:**
+- Smart selective testing based on git diff
+- Volume control (run percentage of affected tests)
+- See [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md#burn-in)
+
+### "We Have Tests But They Always Fail"
+
+**Problem:** Tests are so flaky they're ignored.
+
+**Solution:**
+```
+1. Run *test-review to identify flakiness patterns
+2. Fix top 5 flaky tests (biggest impact)
+3. Quarantine remaining flaky tests
+4. Re-enable as you fix them
+
+Don't let perfect be the enemy of good
+```
+
+## Brownfield TEA Workflow
+
+### Recommended Sequence
+
+**1. Documentation (if needed):**
+```
+*document-project
+```
+
+**2. Baseline (Phase 2):**
+```
+*trace Phase 1 - Establish coverage baseline
+*test-review - Establish quality baseline
+```
+
+**3. Planning (Phase 2-3):**
+```
+*prd - Document requirements (if missing)
+*architecture - Document architecture (if missing)
+*test-design (system-level) - Testability review
+```
+
+**4. Infrastructure (Phase 3):**
+```
+*framework - Modernize test framework (if needed)
+*ci - Setup or improve CI/CD
+```
+
+**5. Per Epic (Phase 4):**
+```
+*test-design (epic-level) - Focus on regression hotspots
+*automate - Add missing tests
+*test-review - Ensure quality
+*trace Phase 1 - Refresh coverage
+```
+
+**6. Release Gate:**
+```
+*nfr-assess - Validate NFRs (if enterprise)
+*trace Phase 2 - Gate decision
+```
+
+## Related Guides
+
+**Workflow Guides:**
+- [How to Run Trace](/docs/how-to/workflows/run-trace.md) - Baseline coverage analysis
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md) - Quality audit
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md) - Fill coverage gaps
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md) - Risk assessment
+
+**Customization:**
+- [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) - Modernize tests with utilities
+
+## Understanding the Concepts
+
+- [Engagement Models](/docs/explanation/tea/engagement-models.md) - Brownfield model explained
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - What makes tests good
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Fix flakiness
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Prioritize improvements
+
+## Reference
+
+- [TEA Command Reference](/docs/reference/tea/commands.md) - All 8 workflows
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Config options
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - Testing patterns
+- [Glossary](/docs/reference/glossary/index.md#test-architect-tea-concepts) - TEA terminology
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/customization/customize-agents.md

@@ -2,8 +2,14 @@
 title: "Agent Customization Guide"
 ---
 
+Use `.customize.yaml` files to customize BMad agents without modifying core files. All customizations persist through updates.
 
-Customize BMad agents without modifying core files. All customizations persist through updates.
+## When to Use This
+
+- Change agent names or personas
+- Add project-specific memories or context
+- Add custom menu items and workflows
+- Define critical actions for consistent behavior
 
 ## Quick Start
 
@@ -204,5 +210,3 @@ memories:
 - **[Learn about Agents](/docs/explanation/core-concepts/what-are-agents.md)** - Understand Simple vs Expert agents
 - **[Agent Creation Guide](/docs/tutorials/advanced/create-custom-agent.md)** - Build completely custom agents
 - **[BMM Complete Documentation](/docs/explanation/bmm/index.md)** - Full BMad Method reference
-
-[← Back to Customization](/docs/how-to/customization/index.md)

docs/how-to/customization/enable-tea-mcp-enhancements.md

@@ -0,0 +1,424 @@
+---
+title: "Enable TEA MCP Enhancements"
+description: Configure Playwright MCP servers for live browser verification during TEA workflows
+---
+
+# Enable TEA MCP Enhancements
+
+Configure Model Context Protocol (MCP) servers to enable live browser verification, exploratory mode, and recording mode in TEA workflows.
+
+## What are MCP Enhancements?
+
+MCP (Model Context Protocol) servers enable AI agents to interact with live browsers during test generation. This allows TEA to:
+
+- **Explore UIs interactively** - Discover actual functionality through browser automation
+- **Verify selectors** - Generate accurate locators from real DOM
+- **Validate behavior** - Confirm test scenarios against live applications
+- **Debug visually** - Use trace viewer and screenshots during generation
+
+## When to Use This
+
+**For UI Testing:**
+- Want exploratory mode in `*test-design` (browser-based UI discovery)
+- Want recording mode in `*atdd` or `*automate` (verify selectors with live browser)
+- Want healing mode in `*automate` (fix tests with visual debugging)
+- Need accurate selectors from actual DOM
+- Debugging complex UI interactions
+
+**For API Testing:**
+- Want healing mode in `*automate` (analyze failures with trace data)
+- Need to debug test failures (network responses, request/response data, timing)
+- Want to inspect trace files (network traffic, errors, race conditions)
+
+**For Both:**
+- Visual debugging (trace viewer shows network + UI)
+- Test failure analysis (MCP can run tests and extract errors)
+- Understanding complex test failures (network + DOM together)
+
+**Don't use if:**
+- You don't have MCP servers configured
+
+## Prerequisites
+
+- BMad Method installed
+- TEA agent available
+- IDE with MCP support (Cursor, VS Code with Claude extension)
+- Node.js v18 or later
+- Playwright installed
+
+## Available MCP Servers
+
+**Two Playwright MCP servers** (actively maintained, continuously updated):
+
+### 1. Playwright MCP - Browser Automation
+
+**Command:** `npx @playwright/mcp@latest`
+
+**Capabilities:**
+- Navigate to URLs
+- Click elements
+- Fill forms
+- Take screenshots
+- Extract DOM information
+
+**Best for:** Exploratory mode, recording mode
+
+### 2. Playwright Test MCP - Test Runner
+
+**Command:** `npx playwright run-test-mcp-server`
+
+**Capabilities:**
+- Run test files
+- Analyze failures
+- Extract error messages
+- Show trace files
+
+**Best for:** Healing mode, debugging
+
+### Recommended: Configure Both
+
+Both servers work together to provide full TEA MCP capabilities.
+
+## Setup
+
+### 1. Configure MCP Servers
+
+Add to your IDE's MCP configuration:
+
+```json
+{
+  "mcpServers": {
+    "playwright": {
+      "command": "npx",
+      "args": ["@playwright/mcp@latest"]
+    },
+    "playwright-test": {
+      "command": "npx",
+      "args": ["playwright", "run-test-mcp-server"]
+    }
+  }
+}
+```
+
+See [TEA Overview](/docs/explanation/features/tea-overview.md#playwright-mcp-enhancements) for IDE-specific config locations.
+
+### 2. Enable in BMAD
+
+Answer "Yes" when prompted during installation, or set in config:
+
+```yaml
+# _bmad/bmm/config.yaml
+tea_use_mcp_enhancements: true
+```
+
+### 3. Verify MCPs Running
+
+Ensure your MCP servers are running in your IDE.
+
+## How MCP Enhances TEA Workflows
+
+### *test-design: Exploratory Mode
+
+**Without MCP:**
+- TEA infers UI functionality from documentation
+- Relies on your description of features
+- May miss actual UI behavior
+
+**With MCP:**
+TEA can open live browser to:
+```
+"Let me explore the profile page to understand the UI"
+
+[TEA navigates to /profile]
+[Takes screenshot]
+[Extracts accessible elements]
+
+"I see the profile has:
+- Name field (editable)
+- Email field (editable)
+- Avatar upload button
+- Save button
+- Cancel button
+
+I'll design tests for these interactions."
+```
+
+**Benefits:**
+- Accurate test design based on actual UI
+- Discovers functionality you might not describe
+- Validates test scenarios are possible
+
+### *atdd: Recording Mode
+
+**Without MCP:**
+- TEA generates selectors from best practices
+- TEA infers API patterns from documentation
+
+**With MCP (Recording Mode):**
+
+**For UI Tests:**
+```
+[TEA navigates to /login with live browser]
+[Inspects actual form fields]
+
+"I see:
+- Email input has label 'Email Address' (not 'Email')
+- Password input has label 'Your Password'
+- Submit button has text 'Sign In' (not 'Login')
+
+I'll use these exact selectors."
+```
+
+**For API Tests:**
+```
+[TEA analyzes trace files from test runs]
+[Inspects network requests/responses]
+
+"I see the API returns:
+- POST /api/login → 200 with { token, userId }
+- Response time: 150ms
+- Required headers: Content-Type, Authorization
+
+I'll validate these in tests."
+```
+
+**Benefits:**
+- UI: Accurate selectors from real DOM
+- API: Validated request/response patterns from trace
+- Both: Tests work on first run
+
+### *automate: Healing + Recording Modes
+
+**Without MCP:**
+- TEA analyzes test code only
+- Suggests fixes based on static analysis
+- Generates tests from documentation/code
+
+**With MCP:**
+
+**Healing Mode (UI + API):**
+```
+[TEA opens trace file]
+[Analyzes screenshots + network tab]
+
+UI failures: "Button selector changed from 'Save' to 'Save Changes'"
+API failures: "Response structure changed, expected {id} got {userId}"
+
+[TEA makes fixes]
+[Verifies with trace analysis]
+```
+
+**Recording Mode (UI + API):**
+```
+UI: [Inspects actual DOM, generates verified selectors]
+API: [Analyzes network traffic, validates request/response patterns]
+
+[Generates tests with verified patterns]
+[Tests work on first run]
+```
+
+**Benefits:**
+- Visual debugging + trace analysis (not just UI)
+- Verified selectors (UI) + network patterns (API)
+- Tests verified against actual application behavior
+
+## Usage Examples
+
+### Exploratory Mode Example
+
+```
+User: Run *test-design
+
+TEA: What feature are you designing tests for?
+
+User: The checkout flow at https://shop.example.com
+
+TEA: [With MCP] Let me explore the checkout flow
+[Opens browser]
+[Navigates to checkout]
+[Takes screenshots]
+[Identifies all interactive elements]
+
+TEA: I've explored the checkout flow. I found:
+- 4-step wizard (Cart → Shipping → Payment → Confirm)
+- Shipping options (Standard, Express, Overnight)
+- Payment methods (Credit Card, PayPal)
+- Promo code field
+- Order summary with real-time totals
+
+Test design will cover all these scenarios.
+```
+
+### Recording Mode Example
+
+```
+User: Run *atdd for user registration feature
+
+TEA: [With MCP] Let me verify the registration form selectors
+[Opens browser at /register]
+[Inspects form]
+
+TEA: I see the actual form has:
+- "Full Name" label (not "Name")
+- "Email Address" label (not "Email")
+- "Create Password" label (not "Password")
+- "I agree to Terms" checkbox
+- "Create Account" button (not "Register")
+
+Generating tests with verified selectors...
+```
+
+### Healing Mode Example
+
+```
+User: Run *automate with healing mode
+
+TEA: [With MCP] Running tests and checking for failures
+[Runs test suite]
+[Test fails: selector not found]
+
+TEA: Test failed on selector '.submit-btn'
+[Opens trace viewer]
+[Sees button class changed to '.submit-button']
+
+Fixing selector and verifying...
+[Updates test]
+[Re-runs with MCP]
+[Test passes]
+
+Updated test with corrected selector.
+```
+
+## Troubleshooting
+
+### MCP Servers Not Running
+
+**Problem:** TEA says MCP enhancements aren't available.
+
+**Causes:**
+1. MCP servers not configured in IDE
+2. Config syntax error in JSON
+3. IDE not restarted after config
+
+**Solution:**
+```bash
+# Verify MCP config file exists
+ls ~/.cursor/config.json
+
+# Validate JSON syntax
+cat ~/.cursor/config.json | python -m json.tool
+
+# Restart IDE
+# Cmd+Q (quit) then reopen
+```
+
+### Browser Doesn't Open
+
+**Problem:** MCP enabled but browser never opens.
+
+**Causes:**
+1. Playwright browsers not installed
+2. Headless mode enabled
+3. MCP server crashed
+
+**Solution:**
+```bash
+# Install browsers
+npx playwright install
+
+# Check MCP server logs (in IDE)
+# Look for error messages
+
+# Try manual MCP server
+npx @playwright/mcp@latest
+# Should start without errors
+```
+
+### TEA Doesn't Use MCP
+
+**Problem:** `tea_use_mcp_enhancements: true` but TEA doesn't use browser.
+
+**Causes:**
+1. Config not saved
+2. Workflow run before config update
+3. MCP servers not running
+
+**Solution:**
+```bash
+# Verify config
+grep tea_use_mcp_enhancements _bmad/bmm/config.yaml
+# Should show: tea_use_mcp_enhancements: true
+
+# Restart IDE (reload MCP servers)
+
+# Start fresh chat (TEA loads config at start)
+```
+
+### Selector Verification Fails
+
+**Problem:** MCP can't find elements TEA is looking for.
+
+**Causes:**
+1. Page not fully loaded
+2. Element behind modal/overlay
+3. Element requires authentication
+
+**Solution:**
+TEA will handle this automatically:
+- Wait for page load
+- Dismiss modals if present
+- Handle auth if needed
+
+If persistent, provide TEA more context:
+```
+"The element is behind a modal - dismiss the modal first"
+"The page requires login - use credentials X"
+```
+
+### MCP Slows Down Workflows
+
+**Problem:** Workflows take much longer with MCP enabled.
+
+**Cause:** Browser automation adds overhead.
+
+**Solution:**
+Use MCP selectively:
+- **Enable for:** Complex UIs, new projects, debugging
+- **Disable for:** Simple features, well-known patterns, API-only testing
+
+Toggle quickly:
+```yaml
+# For this feature (complex UI)
+tea_use_mcp_enhancements: true
+
+# For next feature (simple API)
+tea_use_mcp_enhancements: false
+```
+
+## Related Guides
+
+**Getting Started:**
+- [TEA Lite Quickstart Tutorial](/docs/tutorials/getting-started/tea-lite-quickstart.md) - Learn TEA basics first
+
+**Workflow Guides (MCP-Enhanced):**
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md) - Exploratory mode with browser
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md) - Recording mode for accurate selectors
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md) - Healing mode for debugging
+
+**Other Customization:**
+- [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) - Production-ready utilities
+
+## Understanding the Concepts
+
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - MCP enhancements in lifecycle
+- [Engagement Models](/docs/explanation/tea/engagement-models.md) - When to use MCP enhancements
+
+## Reference
+
+- [TEA Configuration](/docs/reference/tea/configuration.md) - tea_use_mcp_enhancements option
+- [TEA Command Reference](/docs/reference/tea/commands.md) - MCP-enhanced workflows
+- [Glossary](/docs/reference/glossary/index.md#test-architect-tea-concepts) - MCP Enhancements term
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/customization/index.md

@@ -2,7 +2,6 @@
 title: "BMad Customization"
 ---
 
-
 Personalize agents and workflows to match your needs.
 
 ## Guides
@@ -10,18 +9,15 @@ Personalize agents and workflows to match your needs.
 | Guide | Description |
 |-------|-------------|
 | **[Agent Customization](/docs/how-to/customization/customize-agents.md)** | Modify agent behavior without editing core files |
-| **[Workflow Customization](/docs/how-to/customization/customize-workflows.md)** | Customize and optimize workflows |
 
 ## Overview
 
 BMad provides two main customization approaches:
 
 ### Agent Customization
+
 Modify any agent's persona, name, capabilities, or menu items using `.customize.yaml` files in `_bmad/_config/agents/`. Your customizations persist through updates.
 
 ### Workflow Customization
+
 Replace or extend workflow steps to create tailored processes. (Coming soon)
-
----
-
-**Next:** Read the [Agent Customization Guide](/docs/how-to/customization/customize-agents.md) to start personalizing your agents.

docs/how-to/customization/integrate-playwright-utils.md

@@ -0,0 +1,813 @@
+---
+title: "Integrate Playwright Utils with TEA"
+description: Add production-ready fixtures and utilities to your TEA-generated tests
+---
+
+# Integrate Playwright Utils with TEA
+
+Integrate `@seontechnologies/playwright-utils` with TEA to get production-ready fixtures, utilities, and patterns in your test suite.
+
+## What is Playwright Utils?
+
+A production-ready utility library that provides:
+- Typed API request helper
+- Authentication session management
+- Network recording and replay (HAR)
+- Network request interception
+- Async polling (recurse)
+- Structured logging
+- File validation (CSV, PDF, XLSX, ZIP)
+- Burn-in testing utilities
+- Network error monitoring
+
+**Repository:** [https://github.com/seontechnologies/playwright-utils](https://github.com/seontechnologies/playwright-utils)
+
+**npm Package:** `@seontechnologies/playwright-utils`
+
+## When to Use This
+
+- You want production-ready fixtures (not DIY)
+- Your team benefits from standardized patterns
+- You need utilities like API testing, auth handling, network mocking
+- You want TEA to generate tests using these utilities
+- You're building reusable test infrastructure
+
+**Don't use if:**
+- You're just learning testing (keep it simple first)
+- You have your own fixture library
+- You don't need the utilities
+
+## Prerequisites
+
+- BMad Method installed
+- TEA agent available
+- Test framework setup complete (Playwright)
+- Node.js v18 or later
+
+**Note:** Playwright Utils is for Playwright only (not Cypress).
+
+## Installation
+
+### Step 1: Install Package
+
+```bash
+npm install -D @seontechnologies/playwright-utils
+```
+
+### Step 2: Enable in TEA Config
+
+Edit `_bmad/bmm/config.yaml`:
+
+```yaml
+tea_use_playwright_utils: true
+```
+
+**Note:** If you enabled this during BMad installation, it's already set.
+
+### Step 3: Verify Installation
+
+```bash
+# Check package installed
+npm list @seontechnologies/playwright-utils
+
+# Check TEA config
+grep tea_use_playwright_utils _bmad/bmm/config.yaml
+```
+
+Should show:
+```
+@seontechnologies/playwright-utils@2.x.x
+tea_use_playwright_utils: true
+```
+
+## What Changes When Enabled
+
+### *framework Workflow
+
+**Vanilla Playwright:**
+```typescript
+// Basic Playwright fixtures only
+import { test, expect } from '@playwright/test';
+
+test('api test', async ({ request }) => {
+  const response = await request.get('/api/users');
+  const users = await response.json();
+  expect(response.status()).toBe(200);
+});
+```
+
+**With Playwright Utils (Combined Fixtures):**
+```typescript
+// All utilities available via single import
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+import { expect } from '@playwright/test';
+
+test('api test', async ({ apiRequest, authToken, log }) => {
+  const { status, body } = await apiRequest({
+    method: 'GET',
+    path: '/api/users',
+    headers: { Authorization: `Bearer ${authToken}` }
+  });
+
+  log.info('Fetched users', body);
+  expect(status).toBe(200);
+});
+```
+
+**With Playwright Utils (Selective Merge):**
+```typescript
+import { mergeTests } from '@playwright/test';
+import { test as apiRequestFixture } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { test as logFixture } from '@seontechnologies/playwright-utils/log/fixtures';
+
+export const test = mergeTests(apiRequestFixture, logFixture);
+export { expect } from '@playwright/test';
+
+test('api test', async ({ apiRequest, log }) => {
+  log.info('Fetching users');
+  const { status, body } = await apiRequest({
+    method: 'GET',
+    path: '/api/users'
+  });
+  expect(status).toBe(200);
+});
+```
+
+### `*atdd` and `*automate` Workflows
+
+**Without Playwright Utils:**
+```typescript
+// Manual API calls
+test('should fetch profile', async ({ page, request }) => {
+  const response = await request.get('/api/profile');
+  const profile = await response.json();
+  // Manual parsing and validation
+});
+```
+
+**With Playwright Utils:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/api-request/fixtures';
+
+test('should fetch profile', async ({ apiRequest }) => {
+  const { status, body } = await apiRequest({
+    method: 'GET',
+    path: '/api/profile'  // 'path' not 'url'
+  }).validateSchema(ProfileSchema);  // Chained validation
+
+  expect(status).toBe(200);
+  // body is type-safe: { id: string, name: string, email: string }
+});
+```
+
+### *test-review Workflow
+
+**Without Playwright Utils:**
+Reviews against generic Playwright patterns
+
+**With Playwright Utils:**
+Reviews against playwright-utils best practices:
+- Fixture composition patterns
+- Utility usage (apiRequest, authSession, etc.)
+- Network-first patterns
+- Structured logging
+
+### *ci Workflow
+
+**Without Playwright Utils:**
+- Parallel sharding
+- Burn-in loops (basic shell scripts)
+- CI triggers (PR, push, schedule)
+- Artifact collection
+
+**With Playwright Utils:**
+Enhanced with smart testing:
+- Burn-in utility (git diff-based, volume control)
+- Selective testing (skip config/docs/types changes)
+- Test prioritization by file changes
+
+## Available Utilities
+
+### api-request
+
+Typed HTTP client with schema validation.
+
+**Official Docs:** <https://seontechnologies.github.io/playwright-utils/api-request.html>
+
+**Why Use This?**
+
+| Vanilla Playwright | api-request Utility |
+|-------------------|---------------------|
+| Manual `await response.json()` | Automatic JSON parsing |
+| `response.status()` + separate body parsing | Returns `{ status, body }` structure |
+| No built-in retry | Automatic retry for 5xx errors |
+| No schema validation | Single-line `.validateSchema()` |
+| Verbose status checking | Clean destructuring |
+
+**Usage:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { expect } from '@playwright/test';
+import { z } from 'zod';
+
+const UserSchema = z.object({
+  id: z.string(),
+  name: z.string(),
+  email: z.string().email()
+});
+
+test('should create user', async ({ apiRequest }) => {
+  const { status, body } = await apiRequest({
+    method: 'POST',
+    path: '/api/users',  // Note: 'path' not 'url'
+    body: { name: 'Test User', email: 'test@example.com' }  // Note: 'body' not 'data'
+  }).validateSchema(UserSchema);  // Chained method (can await separately if needed)
+
+  expect(status).toBe(201);
+  expect(body.id).toBeDefined();
+  expect(body.email).toBe('test@example.com');
+});
+```
+
+**Benefits:**
+- Returns `{ status, body }` structure
+- Schema validation with `.validateSchema()` chained method
+- Automatic retry for 5xx errors
+- Type-safe response body
+
+### auth-session
+
+Authentication session management with token persistence.
+
+**Official Docs:** <https://seontechnologies.github.io/playwright-utils/auth-session.html>
+
+**Why Use This?**
+
+| Vanilla Playwright Auth | auth-session |
+|------------------------|--------------|
+| Re-authenticate every test run (slow) | Authenticate once, persist to disk |
+| Single user per setup | Multi-user support (roles, accounts) |
+| No token expiration handling | Automatic token renewal |
+| Manual session management | Provider pattern (flexible auth) |
+
+**Usage:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/auth-session/fixtures';
+import { expect } from '@playwright/test';
+
+test('should access protected route', async ({ page, authToken }) => {
+  // authToken automatically fetched and persisted
+  // No manual login needed - handled by fixture
+
+  await page.goto('/dashboard');
+  await expect(page).toHaveURL('/dashboard');
+
+  // Token is reused across tests (persisted to disk)
+});
+```
+
+**Configuration required** (see auth-session docs for provider setup):
+```typescript
+// global-setup.ts
+import { authStorageInit, setAuthProvider, authGlobalInit } from '@seontechnologies/playwright-utils/auth-session';
+
+async function globalSetup() {
+  authStorageInit();
+  setAuthProvider(myCustomProvider);  // Define your auth mechanism
+  await authGlobalInit();  // Fetch token once
+}
+```
+
+**Benefits:**
+- Token fetched once, reused across all tests
+- Persisted to disk (faster subsequent runs)
+- Multi-user support via `authOptions.userIdentifier`
+- Automatic token renewal if expired
+
+### network-recorder
+
+Record and replay network traffic (HAR) for offline testing.
+
+**Official Docs:** <https://seontechnologies.github.io/playwright-utils/network-recorder.html>
+
+**Why Use This?**
+
+| Vanilla Playwright HAR | network-recorder |
+|------------------------|------------------|
+| Manual `routeFromHAR()` configuration | Automatic HAR management with `PW_NET_MODE` |
+| Separate record/playback test files | Same test, switch env var |
+| No CRUD detection | Stateful mocking (POST/PUT/DELETE work) |
+| Manual HAR file paths | Auto-organized by test name |
+
+**Usage:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/network-recorder/fixtures';
+
+// Record mode: Set environment variable
+process.env.PW_NET_MODE = 'record';
+
+test('should work with recorded traffic', async ({ page, context, networkRecorder }) => {
+  // Setup recorder (records or replays based on PW_NET_MODE)
+  await networkRecorder.setup(context);
+
+  // Your normal test code
+  await page.goto('/dashboard');
+  await page.click('#add-item');
+
+  // First run (record): Saves traffic to HAR file
+  // Subsequent runs (playback): Uses HAR file, no backend needed
+});
+```
+
+**Switch modes:**
+```bash
+# Record traffic
+PW_NET_MODE=record npx playwright test
+
+# Playback traffic (offline)
+PW_NET_MODE=playback npx playwright test
+```
+
+**Benefits:**
+- Offline testing (no backend needed)
+- Deterministic responses (same every time)
+- Faster execution (no network latency)
+- Stateful mocking (CRUD operations work)
+
+### intercept-network-call
+
+Spy or stub network requests with automatic JSON parsing.
+
+**Official Docs:** <https://seontechnologies.github.io/playwright-utils/intercept-network-call.html>
+
+**Why Use This?**
+
+| Vanilla Playwright | interceptNetworkCall |
+|-------------------|----------------------|
+| Route setup + response waiting (separate steps) | Single declarative call |
+| Manual `await response.json()` | Automatic JSON parsing (`responseJson`) |
+| Complex filter predicates | Simple glob patterns (`**/api/**`) |
+| Verbose syntax | Concise, readable API |
+
+**Usage:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+
+test('should handle API errors', async ({ page, interceptNetworkCall }) => {
+  // Stub API to return error (set up BEFORE navigation)
+  const profileCall = interceptNetworkCall({
+    method: 'GET',
+    url: '**/api/profile',
+    fulfillResponse: {
+      status: 500,
+      body: { error: 'Server error' }
+    }
+  });
+
+  await page.goto('/profile');
+
+  // Wait for the intercepted response
+  const { status, responseJson } = await profileCall;
+
+  expect(status).toBe(500);
+  expect(responseJson.error).toBe('Server error');
+  await expect(page.getByText('Server error occurred')).toBeVisible();
+});
+```
+
+**Benefits:**
+- Automatic JSON parsing (`responseJson` ready to use)
+- Spy mode (observe real traffic) or stub mode (mock responses)
+- Glob pattern URL matching
+- Returns promise with `{ status, responseJson, requestJson }`
+
+### recurse
+
+Async polling for eventual consistency (Cypress-style).
+
+**Official Docs:** <https://seontechnologies.github.io/playwright-utils/recurse.html>
+
+**Why Use This?**
+
+| Manual Polling | recurse Utility |
+|----------------|-----------------|
+| `while` loops with `waitForTimeout` | Smart polling with exponential backoff |
+| Hard-coded retry logic | Configurable timeout/interval |
+| No logging visibility | Optional logging with custom messages |
+| Verbose, error-prone | Clean, readable API |
+
+**Usage:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+
+test('should wait for async job completion', async ({ apiRequest, recurse }) => {
+  // Start async job
+  const { body: job } = await apiRequest({
+    method: 'POST',
+    path: '/api/jobs'
+  });
+
+  // Poll until complete (smart waiting)
+  const completed = await recurse(
+    () => apiRequest({ method: 'GET', path: `/api/jobs/${job.id}` }),
+    (result) => result.body.status === 'completed',
+    {
+      timeout: 30000,
+      interval: 2000,
+      log: 'Waiting for job to complete'
+    }
+  });
+
+  expect(completed.body.status).toBe('completed');
+});
+```
+
+**Benefits:**
+- Smart polling with configurable interval
+- Handles async jobs, background tasks
+- Optional logging for debugging
+- Better than hard waits or manual polling loops
+
+### log
+
+Structured logging that integrates with Playwright reports.
+
+**Official Docs:** <https://seontechnologies.github.io/playwright-utils/log.html>
+
+**Why Use This?**
+
+| Console.log / print | log Utility |
+|--------------------|-------------|
+| Not in test reports | Integrated with Playwright reports |
+| No step visualization | `.step()` shows in Playwright UI |
+| Manual object formatting | Logs objects seamlessly |
+| No structured output | JSON artifacts for debugging |
+
+**Usage:**
+```typescript
+import { log } from '@seontechnologies/playwright-utils';
+import { test, expect } from '@playwright/test';
+
+test('should login', async ({ page }) => {
+  await log.info('Starting login test');
+
+  await page.goto('/login');
+  await log.step('Navigated to login page');  // Shows in Playwright UI
+
+  await page.getByLabel('Email').fill('test@example.com');
+  await log.debug('Filled email field');
+
+  await log.success('Login completed');
+  // Logs appear in test output and Playwright reports
+});
+```
+
+**Benefits:**
+- Direct import (no fixture needed for basic usage)
+- Structured logs in test reports
+- `.step()` shows in Playwright UI
+- Logs objects seamlessly (no special handling needed)
+- Trace test execution
+
+### file-utils
+
+Read and validate CSV, PDF, XLSX, ZIP files.
+
+**Official Docs:** <https://seontechnologies.github.io/playwright-utils/file-utils.html>
+
+**Why Use This?**
+
+| Vanilla Playwright | file-utils |
+|-------------------|------------|
+| ~80 lines per CSV flow | ~10 lines end-to-end |
+| Manual download event handling | `handleDownload()` encapsulates all |
+| External parsing libraries | Auto-parsing (CSV, XLSX, PDF, ZIP) |
+| No validation helpers | Built-in validation (headers, row count) |
+
+**Usage:**
+```typescript
+import { handleDownload, readCSV } from '@seontechnologies/playwright-utils/file-utils';
+import { expect } from '@playwright/test';
+import path from 'node:path';
+
+const DOWNLOAD_DIR = path.join(__dirname, '../downloads');
+
+test('should export valid CSV', async ({ page }) => {
+  // Handle download and get file path
+  const downloadPath = await handleDownload({
+    page,
+    downloadDir: DOWNLOAD_DIR,
+    trigger: () => page.click('button:has-text("Export")')
+  });
+
+  // Read and parse CSV
+  const csvResult = await readCSV({ filePath: downloadPath });
+  const { data, headers } = csvResult.content;
+
+  // Validate structure
+  expect(headers).toEqual(['Name', 'Email', 'Status']);
+  expect(data.length).toBeGreaterThan(0);
+  expect(data[0]).toMatchObject({
+    Name: expect.any(String),
+    Email: expect.any(String),
+    Status: expect.any(String)
+  });
+});
+```
+
+**Benefits:**
+- Handles downloads automatically
+- Auto-parses CSV, XLSX, PDF, ZIP
+- Type-safe access to parsed data
+- Returns structured `{ headers, data }`
+
+### burn-in
+
+Smart test selection with git diff analysis for CI optimization.
+
+**Official Docs:** <https://seontechnologies.github.io/playwright-utils/burn-in.html>
+
+**Why Use This?**
+
+| Playwright `--only-changed` | burn-in Utility |
+|-----------------------------|-----------------|
+| Config changes trigger all tests | Smart filtering (skip configs, types, docs) |
+| All or nothing | Volume control (run percentage) |
+| No customization | Custom dependency analysis |
+| Slow CI on minor changes | Fast CI with intelligent selection |
+
+**Usage:**
+```typescript
+// scripts/burn-in-changed.ts
+import { runBurnIn } from '@seontechnologies/playwright-utils/burn-in';
+
+async function main() {
+  await runBurnIn({
+    configPath: 'playwright.burn-in.config.ts',
+    baseBranch: 'main'
+  });
+}
+
+main().catch(console.error);
+```
+
+**Config:**
+```typescript
+// playwright.burn-in.config.ts
+import type { BurnInConfig } from '@seontechnologies/playwright-utils/burn-in';
+
+const config: BurnInConfig = {
+  skipBurnInPatterns: [
+    '**/config/**',
+    '**/*.md',
+    '**/*types*'
+  ],
+  burnInTestPercentage: 0.3,
+  burnIn: {
+    repeatEach: 3,
+    retries: 1
+  }
+};
+
+export default config;
+```
+
+**Package script:**
+```json
+{
+  "scripts": {
+    "test:burn-in": "tsx scripts/burn-in-changed.ts"
+  }
+}
+```
+
+**Benefits:**
+- **Ensure flake-free tests upfront** - Never deal with test flake again
+- Smart filtering (skip config, types, docs changes)
+- Volume control (run percentage of affected tests)
+- Git diff-based test selection
+- Faster CI feedback
+
+### network-error-monitor
+
+Automatically detect HTTP 4xx/5xx errors during tests.
+
+**Official Docs:** <https://seontechnologies.github.io/playwright-utils/network-error-monitor.html>
+
+**Why Use This?**
+
+| Vanilla Playwright | network-error-monitor |
+|-------------------|----------------------|
+| UI passes, backend 500 ignored | Auto-fails on any 4xx/5xx |
+| Manual error checking | Zero boilerplate (auto-enabled) |
+| Silent failures slip through | Acts like Sentry for tests |
+| No domino effect prevention | Limits cascading failures |
+
+**Usage:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/network-error-monitor/fixtures';
+
+// That's it! Network monitoring is automatically enabled
+test('should not have API errors', async ({ page }) => {
+  await page.goto('/dashboard');
+  await page.click('button');
+
+  // Test fails automatically if any HTTP 4xx/5xx errors occur
+  // Error message shows: "Network errors detected: 2 request(s) failed"
+  //   GET 500 https://api.example.com/users
+  //   POST 503 https://api.example.com/metrics
+});
+```
+
+**Opt-out for validation tests:**
+```typescript
+// When testing error scenarios, opt-out with annotation
+test('should show error message on 404',
+  { annotation: [{ type: 'skipNetworkMonitoring' }] },  // Array format
+  async ({ page }) => {
+    await page.goto('/invalid-page');  // Will 404
+    await expect(page.getByText('Page not found')).toBeVisible();
+    // Test won't fail on 404 because of annotation
+  }
+);
+
+// Or opt-out entire describe block
+test.describe('error handling',
+  { annotation: [{ type: 'skipNetworkMonitoring' }] },
+  () => {
+    test('handles 404', async ({ page }) => {
+      // Monitoring disabled for all tests in block
+    });
+  }
+);
+```
+
+**Benefits:**
+- Auto-enabled (zero setup)
+- Catches silent backend failures (500, 503, 504)
+- **Prevents domino effect** (limits cascading failures from one bad endpoint)
+- Opt-out with annotations for validation tests
+- Structured error reporting (JSON artifacts)
+
+## Fixture Composition
+
+**Option 1: Use Package's Combined Fixtures (Simplest)**
+
+```typescript
+// Import all utilities at once
+import { test } from '@seontechnologies/playwright-utils/fixtures';
+import { log } from '@seontechnologies/playwright-utils';
+import { expect } from '@playwright/test';
+
+test('api test', async ({ apiRequest, interceptNetworkCall }) => {
+  await log.info('Fetching users');
+
+  const { status, body } = await apiRequest({
+    method: 'GET',
+    path: '/api/users'
+  });
+
+  expect(status).toBe(200);
+});
+```
+
+**Option 2: Create Custom Merged Fixtures (Selective)**
+
+**File 1: support/merged-fixtures.ts**
+```typescript
+import { test as base, mergeTests } from '@playwright/test';
+import { test as apiRequest } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { test as interceptNetworkCall } from '@seontechnologies/playwright-utils/intercept-network-call/fixtures';
+import { test as networkErrorMonitor } from '@seontechnologies/playwright-utils/network-error-monitor/fixtures';
+import { log } from '@seontechnologies/playwright-utils';
+
+// Merge only what you need
+export const test = mergeTests(
+  base,
+  apiRequest,
+  interceptNetworkCall,
+  networkErrorMonitor
+);
+
+export const expect = base.expect;
+export { log };
+```
+
+**File 2: tests/api/users.spec.ts**
+```typescript
+import { test, expect, log } from '../support/merged-fixtures';
+
+test('api test', async ({ apiRequest, interceptNetworkCall }) => {
+  await log.info('Fetching users');
+
+  const { status, body } = await apiRequest({
+    method: 'GET',
+    path: '/api/users'
+  });
+
+  expect(status).toBe(200);
+});
+```
+
+**Contrast:**
+- Option 1: All utilities available, zero setup
+- Option 2: Pick utilities you need, one central file
+
+**See working examples:** <https://github.com/seontechnologies/playwright-utils/tree/main/playwright/support>
+
+## Troubleshooting
+
+### Import Errors
+
+**Problem:** Cannot find module '@seontechnologies/playwright-utils/api-request'
+
+**Solution:**
+```bash
+# Verify package installed
+npm list @seontechnologies/playwright-utils
+
+# Check package.json has correct version
+"@seontechnologies/playwright-utils": "^2.0.0"
+
+# Reinstall if needed
+npm install -D @seontechnologies/playwright-utils
+```
+
+### TEA Not Using Utilities
+
+**Problem:** TEA generates tests without playwright-utils.
+
+**Causes:**
+1. Config not set: `tea_use_playwright_utils: false`
+2. Workflow run before config change
+3. Package not installed
+
+**Solution:**
+```bash
+# Check config
+grep tea_use_playwright_utils _bmad/bmm/config.yaml
+
+# Should show: tea_use_playwright_utils: true
+
+# Start fresh chat (TEA loads config at start)
+```
+
+### Type Errors with apiRequest
+
+**Problem:** TypeScript errors on apiRequest response.
+
+**Cause:** No schema validation.
+
+**Solution:**
+```typescript
+// Add Zod schema for type safety
+import { z } from 'zod';
+
+const ProfileSchema = z.object({
+  id: z.string(),
+  name: z.string(),
+  email: z.string().email()
+});
+
+const { status, body } = await apiRequest({
+  method: 'GET',
+  path: '/api/profile'  // 'path' not 'url'
+}).validateSchema(ProfileSchema);  // Chained method
+
+expect(status).toBe(200);
+// body is typed as { id: string, name: string, email: string }
+```
+
+## Migration Guide
+
+## Related Guides
+
+**Getting Started:**
+- [TEA Lite Quickstart Tutorial](/docs/tutorials/getting-started/tea-lite-quickstart.md) - Learn TEA basics
+- [How to Set Up Test Framework](/docs/how-to/workflows/setup-test-framework.md) - Initial framework setup
+
+**Workflow Guides:**
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md) - Generate tests with utilities
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md) - Expand coverage with utilities
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md) - Review against PW-Utils patterns
+
+**Other Customization:**
+- [Enable MCP Enhancements](/docs/how-to/customization/enable-tea-mcp-enhancements.md) - Live browser verification
+
+## Understanding the Concepts
+
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - **Why Playwright Utils matters** (part of TEA's three-part solution)
+- [Fixture Architecture](/docs/explanation/tea/fixture-architecture.md) - Pure function → fixture pattern
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Network utilities explained
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - Patterns PW-Utils enforces
+
+## Reference
+
+- [TEA Configuration](/docs/reference/tea/configuration.md) - tea_use_playwright_utils option
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - Playwright Utils fragments
+- [Glossary](/docs/reference/glossary/index.md#test-architect-tea-concepts) - Playwright Utils term
+- [Official PW-Utils Docs](https://seontechnologies.github.io/playwright-utils/) - Complete API reference
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/customization/shard-large-documents.md

@@ -2,16 +2,14 @@
 title: "Document Sharding Guide"
 ---
 
+Use the `shard-doc` tool to split large markdown files into smaller, organized files for better context management.
 
-Comprehensive guide to BMad Method's document sharding system for managing large planning and architecture documents.
+## When to Use This
 
-## Table of Contents
-
-- [What is Document Sharding?](#what-is-document-sharding)
-- [When to Use Sharding](#when-to-use-sharding)
-- [How Sharding Works](#how-sharding-works)
-- [Using the Shard-Doc Tool](#using-the-shard-doc-tool)
-- [Workflow Support](#workflow-support)
+- Very large complex PRDs
+- Architecture documents with multiple system layers
+- Epic files with 4+ epics (especially for Phase 4)
+- UX design specs covering multiple subsystems
 
 ## What is Document Sharding?
 
@@ -39,43 +37,15 @@ docs/
     └── ...                         # Additional sections
 ```
 
-## When to Use Sharding
+## Steps
 
-### Ideal Candidates
-
-**Large Multi-Epic Projects:**
-
-- Very large complex PRDs
-- Architecture documents with multiple system layers
-- Epic files with 4+ epics (especially for Phase 4)
-- UX design specs covering multiple subsystems
-
-## How Sharding Works
-
-### Sharding Process
-
-1. **Tool Execution**: Run `npx @kayvan/markdown-tree-parser source.md destination/` - this is abstracted with the core shard-doc task which is installed as a slash command or manual task rule depending on your tools.
-2. **Section Extraction**: Tool splits by level 2 headings
-3. **File Creation**: Each section becomes a separate file
-4. **Index Generation**: `index.md` created with structure and descriptions
-
-### Workflow Discovery
-
-BMad workflows use a **dual discovery system**:
-
-1. **Try whole document first** - Look for `document-name.md`
-2. **Check for sharded version** - Look for `document-name/index.md`
-3. **Priority rule** - Whole document takes precedence if both exist - remove the whole document if you want the sharded to be used instead.
-
-## Using the Shard-Doc Tool
-
-### CLI Command
+### 1. Run the Shard-Doc Tool
 
 ```bash
-/bmad:core:tools:shard-doc 
+/bmad:core:tools:shard-doc
 ```
 
-### Interactive Process
+### 2. Follow the Interactive Process
 
 ```
 Agent: Which document would you like to shard?
@@ -91,7 +61,7 @@ Agent: Sharding PRD.md...
        ✓ Complete!
 ```
 
-### What Gets Created
+## What You Get
 
 **index.md structure:**
 
@@ -113,13 +83,19 @@ Agent: Sharding PRD.md...
 - Preserves all markdown formatting
 - Can be read independently
 
+## How Workflow Discovery Works
+
+BMad workflows use a **dual discovery system**:
+
+1. **Try whole document first** - Look for `document-name.md`
+2. **Check for sharded version** - Look for `document-name/index.md`
+3. **Priority rule** - Whole document takes precedence if both exist - remove the whole document if you want the sharded to be used instead
+
 ## Workflow Support
 
-### Universal Support
+All BMM workflows support both formats:
 
-**All BMM workflows support both formats:**
-
-- ✅ Whole documents
-- ✅ Sharded documents
-- ✅ Automatic detection
-- ✅ Transparent to user
+- Whole documents
+- Sharded documents
+- Automatic detection
+- Transparent to user

docs/how-to/get-answers-about-bmad.md

@@ -3,41 +3,38 @@ title: "How to Get Answers About BMad"
 description: Use an LLM to quickly answer your own BMad questions
 ---
 
-Point an LLM at BMad's source files and ask your question. That's the technique—the rest of this guide shows you how.
+Use your AI tool to get answers about BMad by pointing it at the source files.
 
-## See It Work
+## When to Use This
 
-:::note[Example]
-**Q:** "Tell me the fastest way to build something with BMad"
+- You have a question about how BMad works
+- You want to understand a specific agent or workflow
+- You need quick answers without waiting for Discord
 
-**A:** Use Quick Flow: Run `quick-spec` to write a technical specification, then `quick-dev` to implement it—skipping the full planning phases. This gets small features shipped in a single focused session instead of going through the full 4-phase BMM workflow.
+:::note[Prerequisites]
+An AI tool (Claude Code, Cursor, ChatGPT, Claude.ai, etc.) and either BMad installed in your project or access to the GitHub repo.
 :::
 
-## Why This Works
+## Steps
 
-BMad's prompts are written in plain English, not code. The `_bmad` folder contains readable instructions, workflows, and agent definitions—exactly what LLMs are good at processing. You're not asking the LLM to guess; you're giving it the actual source material.
-
-## How to Do It
-
-### What Each Source Gives You
+### 1. Choose Your Source
 
 | Source | Best For | Examples |
 |--------|----------|----------|
-| **`_bmad` folder** (installed) | How BMad works in detail—agents, workflows, prompts | "What does the PM agent do?" "How does the PRD workflow work?" |
-| **Full GitHub repo** (cloned) | Why things are the way they are—history, installer, architecture | "Why is the installer structured this way?" "What changed in v6?" |
-| **`llms-full.txt`** | Quick overview from documentation perspective | "Explain BMad's four phases" "What's the difference between levels?" |
+| **`_bmad` folder** | How BMad works—agents, workflows, prompts | "What does the PM agent do?" |
+| **Full GitHub repo** | History, installer, architecture | "What changed in v6?" |
+| **`llms-full.txt`** | Quick overview from docs | "Explain BMad's four phases" |
 
-:::note[What's `_bmad`?]
-The `_bmad` folder is created when you install BMad. It contains all the agent definitions, workflows, and prompts. If you don't have this folder yet, you haven't installed BMad—see the "clone the repo" option below.
-:::
+The `_bmad` folder is created when you install BMad. If you don't have it yet, clone the repo instead.
 
-### If Your AI Can Read Files (Claude Code, Cursor, etc.)
+### 2. Point Your AI at the Source
 
-**BMad installed:** Point your LLM at the `_bmad` folder and ask directly.
+**If your AI can read files (Claude Code, Cursor, etc.):**
 
-**Want deeper context:** Clone the [full repo](https://github.com/bmad-code-org/BMAD-METHOD) for git history and installer details.
+- **BMad installed:** Point at the `_bmad` folder and ask directly
+- **Want deeper context:** Clone the [full repo](https://github.com/bmad-code-org/BMAD-METHOD)
 
-### If You Use ChatGPT or Claude.ai
+**If you use ChatGPT or Claude.ai:**
 
 Fetch `llms-full.txt` into your session:
 
@@ -45,12 +42,25 @@ Fetch `llms-full.txt` into your session:
 https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
 ```
 
-You can also find this and other downloadable resources on the [Downloads page](/docs/downloads.md).
+See the [Downloads page](/docs/downloads.md) for other downloadable resources.
 
-:::tip[Verify Surprising Answers]
-LLMs occasionally get things wrong. If an answer seems off, check the source file it referenced or ask on Discord.
+### 3. Ask Your Question
+
+:::note[Example]
+**Q:** "Tell me the fastest way to build something with BMad"
+
+**A:** Use Quick Flow: Run `quick-spec` to write a technical specification, then `quick-dev` to implement it—skipping the full planning phases.
 :::
 
+## What You Get
+
+Direct answers about BMad—how agents work, what workflows do, why things are structured the way they are—without waiting for someone else to respond.
+
+## Tips
+
+- **Verify surprising answers** — LLMs occasionally get things wrong. Check the source file or ask on Discord.
+- **Be specific** — "What does step 3 of the PRD workflow do?" beats "How does PRD work?"
+
 ## Still Stuck?
 
 Tried the LLM approach and still need help? You now have a much better question to ask.
@@ -64,13 +74,7 @@ Tried the LLM approach and still need help? You now have a much better question
 
 **Discord:** [discord.gg/gk8jAdXWmj](https://discord.gg/gk8jAdXWmj)
 
-## Found a Bug?
-
-If it's clearly a bug in BMad itself, skip Discord and go straight to GitHub Issues:
-
-**GitHub Issues:** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues)
-
----
+**GitHub Issues:** [github.com/bmad-code-org/BMAD-METHOD/issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) (for clear bugs)
 
 *You!*
         *Stuck*

docs/how-to/installation/index.md

@@ -3,13 +3,10 @@ title: "Installation Guides"
 description: How to install and upgrade BMad Method
 ---
 
-
 How-to guides for installing and configuring the BMad Method.
 
-## Available Guides
-
 | Guide | Description |
 |-------|-------------|
-| **[Install BMad](/docs/how-to/installation/install-bmad.md)** | Step-by-step installation instructions |
-| **[Install Custom Modules](/docs/how-to/installation/install-custom-modules.md)** | Add custom agents, workflows, and modules |
-| **[Upgrade to v6](/docs/how-to/installation/upgrade-to-v6.md)** | Migrate from BMad v4 to v6 |
+| [Install BMad](/docs/how-to/installation/install-bmad.md) | Step-by-step installation instructions |
+| [Install Custom Modules](/docs/how-to/installation/install-custom-modules.md) | Add custom agents, workflows, and modules |
+| [Upgrade to v6](/docs/how-to/installation/upgrade-to-v6.md) | Migrate from BMad v4 to v6 |

docs/how-to/installation/install-bmad.md

@@ -3,18 +3,19 @@ title: "How to Install BMad"
 description: Step-by-step guide to installing BMad in your project
 ---
 
+Use the `npx bmad-method install` command to set up BMad in your project with your choice of modules and AI tools.
 
-Complete guide to installing BMad in your project.
+## When to Use This
 
----
-
-## Prerequisites
+- Starting a new project with BMad
+- Adding BMad to an existing codebase
+- Update the existing BMad Installation
 
+:::note[Prerequisites]
 - **Node.js** 20+ (required for the installer)
 - **Git** (recommended)
 - **AI-powered IDE** (Claude Code, Cursor, Windsurf, or similar)
-
----
+:::
 
 ## Steps
 
@@ -26,57 +27,42 @@ npx bmad-method install
 
 ### 2. Choose Installation Location
 
-The installer will ask where to install BMad files. Options:
-- Current directory (recommended for new projects)
-- Subdirectory
+The installer will ask where to install BMad files:
+
+- Current directory (recommended for new projects if you created the directory yourself and ran from within the directory)
 - Custom path
 
 ### 3. Select Your AI Tools
 
 Choose which AI tools you'll be using:
+
 - Claude Code
 - Cursor
 - Windsurf
-- Other
+-  Many others to choose from
 
-The installer configures BMad for your selected tools.
+The installer configures BMad for your selected tools by setting up commands that will call the ui.
 
 ### 4. Choose Modules
 
 Select which modules to install:
 
-| Module | Purpose |
-|--------|---------|
-| **BMM** | Core methodology for software development |
-| **BMGD** | Game development workflows |
-| **CIS** | Creative intelligence and facilitation |
-| **BMB** | Building custom agents and workflows |
+| Module   | Purpose                                   |
+| -------- | ----------------------------------------- |
+| **BMM**  | Core methodology for software development |
+| **BMGD** | Game development workflows                |
+| **CIS**  | Creative intelligence and facilitation    |
+| **BMB**  | Building custom agents and workflows      |
 
 ### 5. Add Custom Content (Optional)
 
-If you have custom agents, workflows, or modules:
-- Point to their location
-- The installer will integrate them
+If you have custom agents, workflows, or modules, point to their location and the installer will integrate them.
 
 ### 6. Configure Settings
 
-For each module, either:
-- Accept recommended defaults (faster)
-- Customize settings (more control)
+For each module, either accept recommended defaults (faster) or customize settings (more control).
 
----
-
-## Verify Installation
-
-After installation, verify by:
-
-1. Checking the `_bmad/` directory exists
-2. Loading an agent in your AI tool
-3. Running `*menu` to see available commands
-
----
-
-## Directory Structure
+## What You Get
 
 ```
 your-project/
@@ -91,11 +77,15 @@ your-project/
 └── .claude/            # IDE configuration
 ```
 
----
+## Verify Installation
+
+1. Check the `_bmad/` directory exists
+2. Load an agent in your AI tool
+3. Run `/workflow-init`  which will autocomplete to the full command to see available commands
 
 ## Configuration
 
-Edit `_bmad/[module]/config.yaml` to customize:
+Edit `_bmad/[module]/config.yaml` to customize. For example these could be changed:
 
 ```yaml
 output_folder: ./_bmad-output
@@ -103,36 +93,19 @@ user_name: Your Name
 communication_language: english
 ```
 
----
-
 ## Troubleshooting
 
-### "Command not found: npx"
-
-Install Node.js 20+:
+**"Command not found: npx"** — Install Node.js 20+:
 ```bash
 brew install node
-
 ```
 
-### "Permission denied"
-
-Check npm permissions:
+**"Permission denied"** — Check npm permissions:
 ```bash
 npm config set prefix ~/.npm-global
 ```
 
-### Installer hangs
-
-Try running with verbose output:
+**Installer hangs** — Try running with verbose output:
 ```bash
 npx bmad-method install --verbose
 ```
-
----
-
-## Related
-
-- [Quick Start Guide](/docs/tutorials/getting-started/getting-started-bmadv6.md) - Getting started with BMM
-- [Upgrade to V6](/docs/how-to/installation/upgrade-to-v6.md) - Upgrading from previous versions
-- [Install Custom Modules](/docs/how-to/installation/install-custom-modules.md) - Adding custom content

docs/how-to/installation/install-custom-modules.md

@@ -1,152 +1,118 @@
 ---
-title: "Custom Content Installation"
+title: "How to Install Custom Modules"
+description: Add custom agents, workflows, and modules to BMad
 ---
 
+Use the BMad installer to add custom agents, workflows, and modules that extend BMad's functionality.
 
-This guide explains how to create and install custom BMad content including agents, workflows, and modules. Custom content extends BMad's functionality with specialized tools and workflows that can be shared across projects or teams.
+## When to Use This
 
-For detailed information about the different types of custom content available, see [Custom Content Types](/docs/explanation/bmad-builder/custom-content-types.md).
+- Adding third-party BMad modules to your project
+- Installing your own custom agents or workflows
+- Sharing custom content across projects or teams
 
-You can find example custom modules in the `samples/sample-custom-modules/` folder of the repository. Download either of the sample folders to try them out.
+:::note[Prerequisites]
+- BMad installed in your project
+- Custom content with a valid `module.yaml` file
+:::
 
-## Content Types Overview
+## Steps
 
-BMad Core supports several categories of custom content:
+### 1. Prepare Your Custom Content
 
-- Custom Stand Alone Modules
-- Custom Add On Modules
-- Custom Global Modules
-- Custom Agents
-- Custom Workflows
+Your custom content needs a `module.yaml` file. Choose the appropriate structure:
 
-## Making Custom Content Installable
+**For a cohesive module** (agents and workflows that work together):
 
-### Custom Modules
+```
+module-code/
+  module.yaml
+  agents/
+  workflows/
+  tools/
+  templates/
+```
 
-To create an installable custom module:
+**For standalone items** (unrelated agents/workflows):
 
-1. **Folder Structure**
-   - Create a folder with a short, abbreviated name (e.g., `cis` for Creative Intelligence Suite)
-   - The folder name serves as the module code
+```
+module-name/
+  module.yaml        # Contains unitary: true
+  agents/
+    larry/larry.agent.md
+    curly/curly.agent.md
+  workflows/
+```
 
-2. **Required File**
-   - Include a `module.yaml` file in the root folder (this drives questions for the final generated config.yaml at install target)
+Add `unitary: true` in your `module.yaml` to indicate items don't depend on each other.
 
-3. **Folder Organization**
-   Follow these conventions for optimal compatibility:
+### 2. Run the Installer
 
-   ```
-   module-code/
-     module.yaml
-     agents/
-     workflows/
-     tools/
-     templates/
-     ...
-   ```
+**New project:**
 
-   - `agents/` - Agent definitions
-   - `workflows/` - Workflow definitions
-   - Additional custom folders are supported but following conventions is recommended for agent and workflow discovery
+```bash
+npx bmad-method install
+```
 
-**Note:** Full documentation for global modules and add-on modules will be available as support is finalized.
+When prompted "Would you like to install a local custom module?", select 'y' and provide the path to your module folder.
 
-### Standalone Content (Agents, Workflows, Tasks, Tools, Templates, Prompts)
+**Existing project:**
 
-For standalone content that isn't part of a cohesive module collection, follow this structure:
+```bash
+npx bmad-method install
+```
 
-1. **Module Configuration**
-   - Create a folder with a `module.yaml` file (similar to custom modules)
-   - Add the property `unitary: true` in the module.yaml
-     - The `unitary: true` property indicates this is a collection of potentially unrelated items that don't depend on each other
-   - Any content you add to this folder should still be nested under workflows and agents - but the key with stand alone content is they do not rely on each other.
-     - Agents do not reference other workflows even if stored in a unitary:true module. But unitary Agents can have their own workflows in their sidecar, or reference workflows as requirements from other modules - with a process known as workflow vendoring. Keep in mind, this will require that the workflow referenced from the other module would need to be available for the end user to install, so its recommended to only vendor workflows from the core module, or official bmm modules.
+1. Select `Modify BMad Installation`
+2. Choose the option to add, modify, or update custom modules
+3. Provide the path to your module folder
 
-2. **Folder Structure**
-   Organize content in specific named folders:
+### 3. Verify Installation
 
-   ```
-   module-name/
-     module.yaml        # Contains unitary: true
-     agents/
-     workflows/
-     templates/
-     tools/
-     tasks/
-     prompts/
-   ```
+Check that your custom content appears in the `_bmad/` directory and is accessible from your AI tool.
 
-3. **Individual Item Organization**
-   Each item should have its own subfolder:
-   ```text
-   my-custom-stuff/
-     module.yaml
-     agents/
-       larry/larry.agent.md
-       curly/curly.agent.md
-       moe/moe.agent.md
-       moe/moe-sidecar/memories.csv
-   ```
+## What You Get
 
-**Future Feature:** Unitary modules will support selective installation, allowing users to pick and choose which specific items to install.
+- Custom agents available in your AI tool
+- Custom workflows accessible via `*workflow-name`
+- Content integrated with BMad's update system
 
-**Note:** Documentation explaining the distinctions between these content types and their specific use cases will be available soon.
+## Content Types
 
-## Installation Process
+BMad supports several categories of custom content:
 
-### Prerequisites
+| Type | Description |
+|------|-------------|
+| **Stand Alone Modules** | Complete modules with their own agents and workflows |
+| **Add On Modules** | Extensions that add to existing modules |
+| **Global Modules** | Content available across all modules |
+| **Custom Agents** | Individual agent definitions |
+| **Custom Workflows** | Individual workflow definitions |
 
-Ensure your content follows the proper conventions and includes a `module.yaml` file (only one per top-level folder).
+For detailed information about content types, see [Custom Content Types](/docs/explanation/bmad-builder/custom-content-types.md).
 
-### New Project Installation
+## Updating Custom Content
 
-When setting up a new BMad project:
+When BMad Core or module updates are available, the quick update process:
 
-1. The installer will prompt: `Would you like to install a local custom module (this includes custom agents and workflows also)? (y/N)`
-2. Select 'y' to specify the path to your module folder containing `module.yaml`
+1. Applies updates to core modules
+2. Recompiles all agents with your customizations
+3. Retains your custom content from cache
+4. Preserves your configurations
 
-### Existing Project Modification
+You don't need to keep source module files locally—just point to the updated location during updates.
 
-To add custom content to an existing BMad project:
+## Tips
 
-1. Run the installer against your project location
-2. Select `Modify BMad Installation`
-3. Choose the option to add, modify, or update custom modules
+- **Use unique module codes** — Don't use `bmm` or other existing module codes
+- **Avoid naming conflicts** — Each module needs a distinct code
+- **Document dependencies** — Note any modules your custom content requires
+- **Test in isolation** — Verify custom modules work before sharing
+- **Version your content** — Track updates with version numbers
 
-### Upcoming Features
+:::caution[Naming Conflicts]
+Don't create custom modules with codes like `bmm` (already used by BMad Method). Each custom module needs a unique code.
+:::
 
-- **Unitary Module Selection:** For modules with `type: unitary` (instead of `type: module`), you'll be able to select specific items to install
-- **Add-on Module Dependencies:** The installer will verify and install dependencies for add-on modules automatically
+## Example Modules
 
-## Quick Updates
-
-When updates to BMad Core or core modules (BMM, CIS, etc.) become available, the quick update process will:
-
-1. Apply available updates to core modules
-2. Recompile all agents with customizations from the `_config/agents` folder
-3. Retain your custom content from a cached location
-4. Preserve your existing configurations and customizations
-
-This means you don't need to keep the source module files locally. When updates are available, simply point to the updated module location during the update process.
-
-## Important Considerations
-
-### Module Naming Conflicts
-
-When installing unofficial modules, ensure unique identification to avoid conflicts:
-
-1. **Module Codes:** Each module must have a unique code (e.g., don't use `bmm` for custom modules)
-2. **Module Names:** Avoid using names that conflict with existing modules
-3. **Multiple Custom Modules:** If creating multiple custom modules, use distinct codes for each
-
-**Examples of conflicts to avoid:**
-
-- Don't create a custom module with code `bmm` (already used by BMad Method)
-- Don't name multiple custom modules with the same code like `mca`
-
-### Best Practices
-
-- Use descriptive, unique codes for your modules
-- Document any dependencies your custom modules have
-- Test custom modules in isolation before sharing
-- Consider version numbering for your custom content to track updates
+Find example custom modules in the `samples/sample-custom-modules/` folder of the [BMad repository](https://github.com/bmad-code-org/BMAD-METHOD). Download either sample folder to try them out.

docs/how-to/installation/upgrade-to-v6.md

@@ -1,147 +1,131 @@
 ---
-title: "Upgrading from Previous Versions"
+title: "How to Upgrade to v6"
+description: Migrate from BMad v4 to v6
 ---
 
+Use the BMad installer to upgrade from v4 to v6, which includes automatic detection of legacy installations and migration assistance.
 
-## Overview
+## When to Use This
 
-The latest version of BMad represents a complete ground-up rewrite with significant architectural changes. This guide will help you migrate from version 4.
+- You have BMad v4 installed (`.bmad-method` folder)
+- You want to migrate to the new v6 architecture
+- You have existing planning artifacts to preserve
 
----
+:::note[Prerequisites]
+- Node.js 20+
+- Existing BMad v4 installation
+:::
 
-## Automatic V4 Detection
+## Steps
 
-When you run `npm run install:bmad` on a project, the installer automatically detects:
+### 1. Run the Installer
 
-- **Legacy v4 installation folder**: `.bmad-method`
-- **IDE command artifacts**: Legacy bmad folders in IDE configuration directories (`.claude/commands/`, `.cursor/commands/`, etc.)
-
-### What Happens During Detection
-
-1. **Automatic Detection of v4 Modules**
-   1. Installer will suggest removal or backup of your .bmad-method folder. You can choose to exit the installer and handle this cleanup, or allow the install to continue. Technically you can have both v4 and v6 installed, but it is not recommended. All BMad content and modules will be installed under a .bmad folder, fully segregated.
-
-2. **IDE Command Cleanup Recommended**: Legacy v4 IDE commands should be manually removed
-   - Located in IDE config folders, for example claude: `.claude/commands/BMad/agents`, `.claude/commands/BMad/tasks`, etc.
-   - NOTE: if the upgrade and install of v6 finished, the new commands will be under `.claude/commands/bmad/<module>/agents|workflows`
-   - Note 2: If you accidentally delete the wrong/new bmad commands - you can easily restore them by rerunning the installer, and choose quick update option, and all will be reapplied properly.
-
-## Module Migration
-
-### Deprecated Modules from v4
-
-| v4 Module                     | v6 Status                                      |
-| ----------------------------- | ---------------------------------------------- |
-| `_bmad-2d-phaser-game-dev`    | Integrated into new BMGD Module                |
-| `_bmad-2d-unity-game-dev`     | Integrated into new BMGD Module                |
-| `_bmad-godot-game-dev`        | Integrated into new BMGD Module                |
-| `_bmad-*-game-dev` (any)      | Integrated into new BMGD Module                |
-| `_bmad-infrastructure-devops` | Deprecated - New core devops agent coming soon |
-| `_bmad-creative-writing`      | Not adapted - New v6 module coming soon        |
-
-Aside from .bmad-method - if you have any of these others installed also, again its recommended to remove them and use the V6 equivalents, but its also fine if you decide to keep both. But it is not recommended to use both on the same project long term.
-
-## Architecture Changes
-
-### Folder Structure
-
-**v4 "Expansion Packs" Structure:**
-
-```
-your-project/
-├── .bmad-method/         
-├── .bmad-game-dev/       
-├── .bmad-creative-writing/
-└── .bmad-infrastructure-devops/
+```bash
+npx bmad-method install
 ```
 
-**v6 Unified Structure:**
+The installer automatically detects:
 
-```
-your-project/
-└── _bmad/               # Single installation folder is _bmad
-    └── _config/         # Your customizations
-    |  └── agents/       # Agent customization files
-    ├── core/            # Real core framework (applies to all modules)
-    ├── bmm/             # BMad Method (software/game dev)
-    ├── bmb/             # BMad Builder (create agents/workflows)
-    ├── cis/             # Creative Intelligence Suite
-├── _bmad_output         # Default bmad output folder (was doc folder in v4)
+- **Legacy v4 folder**: `.bmad-method`
+- **IDE command artifacts**: Legacy bmad folders in `.claude/commands/`, `.cursor/commands/`, etc.
 
-```
+### 2. Handle Legacy Installation
 
-### Key Concept Changes
+When v4 is detected, you can:
 
-- **v4 `_bmad-core and _bmad-method`**: Was actually the BMad Method
-- **v6 `_bmad/core/`**: Is the real universal core framework
-- **v6 `_bmad/bmm/`**: Is the BMad Method module
-- **Module identification**: All modules now have a `config.yaml` file once installed at the root of the modules installed folder
+- Allow the installer to back up and remove `.bmad-method`
+- Exit and handle cleanup manually
+- Keep both (not recommended for same project)
 
-## Project Progress Migration
+### 3. Clean Up IDE Commands
 
-### If You've Completed Some or all Planning Phases (Brief/PRD/UX/Architecture) with the BMad Method:
+Manually remove legacy v4 IDE commands:
 
-After running the v6 installer, if you kept the paths the same as the installation suggested, you will need to move a few files, or run the installer again. It is recommended to stick with these defaults as it will be easier to adapt if things change in the future.
+- `.claude/commands/BMad/agents`
+- `.claude/commands/BMad/tasks`
 
-If you have any planning artifacts, put them in a folder called _bmad-output/planning-artifacts at the root of your project, ensuring that:
-PRD has PRD in the file name or folder name if sharded.
-Similar for 'brief', 'architecture', 'ux-design'.
+New v6 commands will be at `.claude/commands/bmad/<module>/agents|workflows`.
 
-If you have other long term docs that will not be as ephemeral as these project docs, you can put them in the /docs folder, ideally with a index.md file.
+:::tip[Accidentally Deleted Commands?]
+If you delete the wrong commands, rerun the installer and choose "quick update" to restore them.
+:::
 
-HIGHLY RECOMMENDED NOTE: If you are only partway through planning, its highly recommended to restart and do the PRD, UX and ARCHITECTURE steps. You could even use your existing documents as inputs letting the agent know you want to redo them with the new workflows. These optimized v6 progressive discovery workflows that also will utilize web search at key moments, while offering better advanced elicitation and part mode in the IDE will produce superior results. And then once all are complete, an epics with stories is generated after the architecture step now - ensuring it uses input from all planing documents.
+### 4. Migrate Planning Artifacts
 
-### If You're Mid-Development (Stories Created/Implemented)
+**If you have planning documents (Brief/PRD/UX/Architecture):**
 
-1. Complete the v6 installation as above
-2. Ensure you have a file called epics.md or epics/epic*.md - these need to be located under the _bmad-output/planning-artifacts folder.
-3. Run the scrum masters `sprint-planning` workflow to generate the implementation tracking plan in _bmad-output/implementation-artifacts.
-4. Inform the SM after the output is complete which epics and stories were completed already and should be parked properly in the file.
+Move them to `_bmad-output/planning-artifacts/` with descriptive names:
 
-## Agent Customization Migration
+- Include `PRD` in filename for PRD documents
+- Include `brief`, `architecture`, or `ux-design` accordingly
+- Sharded documents can be in named subfolders
 
-### v4 Agent Customization
+**If you're mid-planning:** Consider restarting with v6 workflows. Use your existing documents as inputs—the new progressive discovery workflows with web search and IDE plan mode produce better results.
 
-In v4, you may have modified agent files directly in `_bmad-*` folders.
+### 5. Migrate In-Progress Development
 
-### v6 Agent Customization
+If you have stories created or implemented:
 
-**All customizations** now go in `_bmad/_config/agents/` using customize files:
+1. Complete the v6 installation
+2. Place `epics.md` or `epics/epic*.md` in `_bmad-output/planning-artifacts/`
+3. Run the Scrum Master's `sprint-planning` workflow
+4. Tell the SM which epics/stories are already complete
 
-**Example: Renaming an agent and changing communication style**
+### 6. Migrate Agent Customizations
 
-File: `_bmad/_config/agents/bmm-pm.customize.yaml`
+**v4:** Modified agent files directly in `_bmad-*` folders
+
+**v6:** All customizations go in `_bmad/_config/agents/` using customize files:
 
 ```yaml
-# Customize the PM agent
+# _bmad/_config/agents/bmm-pm.customize.yaml
 persona:
-  name: 'Captain Jack' # Override agent name
+  name: 'Captain Jack'
   role: 'Swashbuckling Product Owner'
   communication_style: |
     - Talk like a pirate
-    - Use nautical metaphors for software concepts
-    - Always upbeat and adventurous
+    - Use nautical metaphors
 ```
 
-There is a lot more that is possible with agent customization, which is covered in detail in the [Agent Customization Guide](/docs/how-to/customization/customize-agents.md)
+After modifying customization files, rerun the installer and choose "rebuild all agents" or "quick update".
 
-CRITICAL NOTE: After you modify the customization file, you need to run the npx installer against your installed location, and choose the option to rebuild all agents, or just do a quick update again. This always builds agents fresh and applies customizations.
+## What You Get
 
-**How it works:**
+**v6 unified structure:**
 
-- Base agent: `_bmad/bmm/agents/pm.md`
-- Customization: `_bmad/_config/agents/bmm-pm.customize.yaml`
-- Rebuild all agents -> Result: Agent uses your custom name and style
+```
+your-project/
+└── _bmad/               # Single installation folder
+    ├── _config/         # Your customizations
+    │   └── agents/      # Agent customization files
+    ├── core/            # Universal core framework
+    ├── bmm/             # BMad Method module
+    ├── bmb/             # BMad Builder
+    └── cis/             # Creative Intelligence Suite
+├── _bmad-output/        # Output folder (was doc folder in v4)
+```
 
-## Document Compatibility
+## Module Migration
 
-### Sharded vs Unsharded Documents
+| v4 Module | v6 Status |
+|-----------|-----------|
+| `_bmad-2d-phaser-game-dev` | Integrated into BMGD Module |
+| `_bmad-2d-unity-game-dev` | Integrated into BMGD Module |
+| `_bmad-godot-game-dev` | Integrated into BMGD Module |
+| `_bmad-infrastructure-devops` | Deprecated — new DevOps agent coming soon |
+| `_bmad-creative-writing` | Not adapted — new v6 module coming soon |
 
-**Good news**: Unlike v4, v6 workflows are **fully flexible** with document structure:
+## Key Changes
 
-- ✅ Sharded documents (split into multiple files)
-- ✅ Unsharded documents (single file per section)
-- ✅ Custom sections for your project type
-- ✅ Mixed approaches
+| Concept | v4 | v6 |
+|---------|----|----|
+| **Core** | `_bmad-core` was actually BMad Method | `_bmad/core/` is universal framework |
+| **Method** | `_bmad-method` | `_bmad/bmm/` |
+| **Config** | Modified files directly | `config.yaml` per module |
+| **Documents** | Sharded or unsharded required setup | Fully flexible, auto-scanned |
 
-All workflow files are scanned automatically. No manual configuration needed.
+## Tips
+
+- **Back up first** — Keep your v4 installation until you verify v6 works
+- **Use v6 workflows** — Even partial planning docs benefit from v6's improved discovery
+- **Rebuild after customizing** — Always run the installer after changing customize files

docs/how-to/troubleshooting/bmgd-troubleshooting.md

@@ -2,10 +2,7 @@
 title: "BMGD Troubleshooting"
 ---
 
-
-Common issues and solutions when using BMGD workflows.
-
----
+Use this guide to resolve common issues when using BMGD workflows.
 
 ## Installation Issues
 
@@ -19,8 +16,6 @@ Common issues and solutions when using BMGD workflows.
 2. Check `_bmad/bmgd/` folder exists in your project
 3. Re-run installer with `--add-module bmgd`
 
----
-
 ### Config file missing
 
 **Symptom:** Workflows fail with "config not found" errors.
@@ -36,8 +31,6 @@ document_output_language: 'English'
 game_dev_experience: 'intermediate'
 ```
 
----
-
 ## Workflow Issues
 
 ### "GDD not found" in Narrative workflow
@@ -50,8 +43,6 @@ game_dev_experience: 'intermediate'
 2. Check GDD filename contains "gdd" (e.g., `game-gdd.md`, `my-gdd.md`)
 3. If using sharded GDD, verify `{output_folder}/gdd/index.md` exists
 
----
-
 ### Workflow state not persisting
 
 **Symptom:** Returning to a workflow starts from the beginning.
@@ -62,8 +53,6 @@ game_dev_experience: 'intermediate'
 2. Ensure document was saved before ending session
 3. Use "Continue existing" option when re-entering workflow
 
----
-
 ### Wrong game type sections in GDD
 
 **Symptom:** GDD includes irrelevant sections for your game type.
@@ -74,8 +63,6 @@ game_dev_experience: 'intermediate'
 2. You can select multiple types for hybrid games
 3. Irrelevant sections can be marked N/A or removed
 
----
-
 ## Agent Issues
 
 ### Agent not recognizing commands
@@ -88,8 +75,6 @@ game_dev_experience: 'intermediate'
 2. Check exact command spelling (case-sensitive)
 3. Try `workflow-status` to verify agent is loaded correctly
 
----
-
 ### Agent using wrong persona
 
 **Symptom:** Agent responses don't match expected personality.
@@ -100,8 +85,6 @@ game_dev_experience: 'intermediate'
 2. Check `_bmad/bmgd/agents/` for agent definitions
 3. Start a fresh chat session with the correct agent
 
----
-
 ## Document Issues
 
 ### Document too large for context
@@ -114,8 +97,6 @@ game_dev_experience: 'intermediate'
 2. Request specific sections rather than full document
 3. GDD workflow supports automatic sharding for large documents
 
----
-
 ### Template placeholders not replaced
 
 **Symptom:** Output contains `{{placeholder}}` text.
@@ -126,8 +107,6 @@ game_dev_experience: 'intermediate'
 2. Re-run the specific step that generates that section
 3. Manually edit the document to fill in missing values
 
----
-
 ### Frontmatter parsing errors
 
 **Symptom:** YAML errors when loading documents.
@@ -138,8 +117,6 @@ game_dev_experience: 'intermediate'
 2. Check for tabs vs spaces (YAML requires spaces)
 3. Ensure frontmatter is bounded by `---` markers
 
----
-
 ## Phase 4 (Production) Issues
 
 ### Sprint status not updating
@@ -152,8 +129,6 @@ game_dev_experience: 'intermediate'
 2. Check file permissions on sprint-status.yaml
 3. Verify workflow-install files exist in `_bmad/bmgd/workflows/4-production/`
 
----
-
 ### Story context missing code references
 
 **Symptom:** Generated story context doesn't include relevant code.
@@ -164,8 +139,6 @@ game_dev_experience: 'intermediate'
 2. Check that architecture document references correct file paths
 3. Story may need more specific file references in acceptance criteria
 
----
-
 ### Code review not finding issues
 
 **Symptom:** Code review passes but bugs exist.
@@ -176,8 +149,6 @@ game_dev_experience: 'intermediate'
 2. Always run actual tests before marking story done
 3. Consider manual review for critical code paths
 
----
-
 ## Performance Issues
 
 ### Workflows running slowly
@@ -190,8 +161,6 @@ game_dev_experience: 'intermediate'
 2. Keep documents concise (avoid unnecessary detail)
 3. Use sharded documents for large projects
 
----
-
 ### Context limit reached mid-workflow
 
 **Symptom:** Workflow stops or loses context partway through.
@@ -202,8 +171,6 @@ game_dev_experience: 'intermediate'
 2. Break complex sections into multiple sessions
 3. Use step-file architecture (workflows resume from last step)
 
----
-
 ## Common Error Messages
 
 ### "Input file not found"
@@ -212,24 +179,18 @@ game_dev_experience: 'intermediate'
 
 **Fix:** Complete prerequisite workflow first (e.g., Game Brief before GDD).
 
----
-
 ### "Invalid game type"
 
 **Cause:** Selected game type not in supported list.
 
 **Fix:** Check `game-types.csv` for valid type IDs.
 
----
-
 ### "Validation failed"
 
 **Cause:** Document doesn't meet checklist requirements.
 
 **Fix:** Review the validation output and address flagged items.
 
----
-
 ## Getting Help
 
 ### Community Support
@@ -252,10 +213,7 @@ When reporting issues, include:
 3. Relevant document frontmatter
 4. Steps to reproduce
 
----
-
 ## Next Steps
 
-- **[Quick Start Guide](/docs/tutorials/getting-started/quick-start-bmgd.md)** - Getting started
 - **[Workflows Guide](/docs/reference/workflows/index.md)** - Workflow reference
 - **[Glossary](/docs/reference/glossary/index.md)** - Terminology

docs/how-to/workflows/bmgd-quick-flow.md

@@ -1,52 +1,41 @@
 ---
 title: "BMGD Quick-Flow Guide"
+description: Fast-track workflows for rapid game prototyping and flexible development
 ---
 
+Use BMGD Quick-Flow workflows for rapid game prototyping and flexible development when you need to move fast.
 
-Fast-track workflows for rapid game prototyping and flexible development.
-
----
-
-## Game Solo Dev Agent
-
-For dedicated quick-flow development, use the **Game Solo Dev** agent (Indie). This agent is optimized for solo developers and small teams who want to skip the full planning phases and ship fast.
-
-**Switch to Game Solo Dev:** Type `@game-solo-dev` or select the agent from your IDE.
-
-The Game Solo Dev agent includes:
-
-- `quick-prototype` - Rapid mechanic testing
-- `quick-dev` - Flexible feature implementation
-- `quick-spec` - Create implementation-ready specs
-- `code-review` - Quality checks
-- `test-framework` - Automated testing setup
-
----
-
-## Overview
-
-Quick-flow workflows skip the full BMGD planning phases when you need to move fast. Use them for:
+## When to Use This
 
 - Testing a game mechanic idea
 - Implementing a small feature
 - Rapid prototyping before committing to design
 - Bug fixes and tweaks
 
-```
-Full BMGD Flow:
-Brief → GDD → Architecture → Sprint Planning → Stories → Implementation
+## When to Use Full BMGD Instead
 
-Quick-Flow:
-Idea → Quick-Prototype → Quick-Dev → Done
-```
+- Building a major feature or system
+- The scope is unclear or large
+- Multiple team members need alignment
+- The work affects game pillars or core loop
+- You need documentation for future reference
 
----
+:::note[Prerequisites]
+- BMad Method installed with BMGD module
+- Game Solo Dev agent (Indie) or other BMGD agent available
+:::
+
+## Game Solo Dev Agent
+
+For dedicated quick-flow development, use the **Game Solo Dev** agent. This agent is optimized for solo developers and small teams who want to skip the full planning phases.
+
+**Switch to Game Solo Dev:** Type `@game-solo-dev` or select from your IDE.
+
+Includes: `quick-prototype`, `quick-dev`, `quick-spec`, `code-review`, `test-framework`
 
 ## Quick-Prototype
 
-**Command:** `quick-prototype`
-**Agent:** Game Designer, Game Developer
-**Purpose:** Rapidly test gameplay ideas with minimal setup
+Use `quick-prototype` to rapidly test gameplay ideas with minimal setup.
 
 ### When to Use
 
@@ -55,60 +44,31 @@ Idea → Quick-Prototype → Quick-Dev → Done
 - You want to experiment before committing to design
 - You need a proof of concept
 
-### Workflow Steps
+### Steps
 
-1. **Define Scope** - What are you prototyping? (mechanic, feature, system)
-2. **Set Success Criteria** - How will you know if it works?
-3. **Rapid Implementation** - Build the minimum to test the idea
-4. **Playtest and Evaluate** - Does it feel right?
+1. Run `quick-prototype`
+2. Define what you're prototyping (mechanic, feature, system)
+3. Set success criteria (2-3 items)
+4. Build the minimum to test the idea
+5. Playtest and evaluate
 
 ### Prototype Principles
 
-- **Minimum Viable Prototype** - Only what's needed to test the idea
-- **Hardcode First** - Magic numbers are fine, extract later
-- **Skip Edge Cases** - Happy path only for now
-- **Placeholder Everything** - Cubes, debug text, temp sounds
-- **Comment Intent** - Mark what's temporary vs keeper code
-
-### Example Session
-
-```
-You: quick-prototype
-
-Agent: What are you prototyping?
-
-You: I want to test a grappling hook mechanic. Player should be
-     able to aim at surfaces and pull themselves toward the hook point.
-
-Agent: What makes this prototype successful?
-
-You: 1. Aiming feels responsive and intuitive
-     2. The pull movement feels satisfying, not floaty
-     3. Player can chain hooks without awkward pauses
-
-Agent: [Implements minimal grappling hook]
-
-Agent: Prototype complete! Playtest results:
-     - Aiming: Works, consider adding aim assist
-     - Movement: Pull is smooth, might need speed curve
-     - Chaining: Currently has 0.2s delay, feels sluggish
-
-     Next: [d] Develop further | [i] Iterate | [a] Archive
-```
+- **Minimum Viable Prototype** — Only what's needed to test the idea
+- **Hardcode First** — Magic numbers are fine, extract later
+- **Skip Edge Cases** — Happy path only for now
+- **Placeholder Everything** — Cubes, debug text, temp sounds
+- **Comment Intent** — Mark what's temporary vs keeper code
 
 ### After Prototyping
 
-- **Develop** (`d`) - Use `quick-dev` to build production code
-- **Iterate** (`i`) - Adjust and re-test the prototype
-- **Archive** (`a`) - Keep as reference, move on to other ideas
-
----
+- **Develop** (`d`) — Use `quick-dev` to build production code
+- **Iterate** (`i`) — Adjust and re-test the prototype
+- **Archive** (`a`) — Keep as reference, move on to other ideas
 
 ## Quick-Dev
 
-**Command:** `quick-dev`
-**Agent:** Game Developer
-**Purpose:** Flexible development with game-specific considerations
+Use `quick-dev` for flexible development with game-specific considerations.
 
 ### When to Use
 
@@ -120,172 +80,77 @@ Agent: Prototype complete! Playtest results:
 ### Workflow Modes
 
 **Mode A: Tech-Spec Driven**
-
 ```
-You: quick-dev tech-spec-combat.md
-Agent: [Loads spec, extracts tasks, implements]
+quick-dev tech-spec-combat.md
 ```
 
 **Mode B: Direct Instructions**
-
 ```
-You: quick-dev implement double-jump for the player
-Agent: [Evaluates complexity, offers planning options]
+quick-dev implement double-jump for the player
 ```
 
 **Mode C: From Prototype**
-
 ```
-You: quick-dev from the grappling hook prototype
-Agent: [Loads prototype, productionizes code]
+quick-dev from the grappling hook prototype
 ```
 
 ### Game-Specific Checks
 
 Quick-dev includes automatic consideration of:
-
-- **Performance** - No allocations in hot paths, object pooling
-- **Feel** - Input responsiveness, visual/audio feedback
-- **Integration** - Save/load, multiplayer sync, platform testing
-
-### Example Session
-
-```
-You: quick-dev implement enemy patrol behavior
-
-Agent: This looks like a focused feature. Options:
-       [t] Plan first - Create tech-spec (recommended)
-       [r] Prototype first - Test the idea
-       [e] Execute directly
-
-You: e
-
-Agent: Any additional guidance? (patterns, files, constraints)
-
-You: Use the existing AIController base class. Enemies should
-     patrol between waypoints and return if player leaves range.
-
-Agent: [Implements patrol behavior]
-
-Agent: Implementation Complete!
-       Files Modified: EnemyAI.cs, PatrolBehavior.cs
-       Tests: Unit tests added for patrol state machine
-       Performance: No per-frame allocations
-
-       Recommended: Playtest the changes
-```
+- **Performance** — No allocations in hot paths, object pooling
+- **Feel** — Input responsiveness, visual/audio feedback
+- **Integration** — Save/load, multiplayer sync, platform testing
 
 ### Complexity Routing
 
-Quick-dev automatically detects complex requests and offers alternatives:
-
-| Signals                                | Recommendation         |
-| -------------------------------------- | ---------------------- |
-| Single mechanic, bug fix, tweak        | Execute directly       |
+| Signals | Recommendation |
+|---------|----------------|
+| Single mechanic, bug fix, tweak | Execute directly |
 | Multiple systems, performance-critical | Plan first (tech-spec) |
-| Platform/system level work             | Use full BMGD workflow |
-
----
+| Platform/system level work | Use full BMGD workflow |
 
 ## Choosing Between Quick-Flows
 
-| Scenario                | Use                             |
-| ----------------------- | ------------------------------- |
-| "Will this be fun?"     | `quick-prototype`               |
-| "How should this feel?" | `quick-prototype`               |
-| "Build this feature"    | `quick-dev`                     |
-| "Fix this bug"          | `quick-dev`                     |
-| "Test then build"       | `quick-prototype` → `quick-dev` |
+| Scenario | Use |
+|----------|-----|
+| "Will this be fun?" | `quick-prototype` |
+| "How should this feel?" | `quick-prototype` |
+| "Build this feature" | `quick-dev` |
+| "Fix this bug" | `quick-dev` |
+| "Test then build" | `quick-prototype` → `quick-dev` |
 
----
+## Flow Comparison
 
-## Quick-Flow vs Full BMGD
+```
+Full BMGD Flow:
+Brief → GDD → Architecture → Sprint Planning → Stories → Implementation
 
-### Use Quick-Flow When
-
-- The scope is small and well-understood
-- You're experimenting or prototyping
-- You have a clear tech-spec already
-- The work doesn't affect core game systems significantly
-
-### Use Full BMGD When
-
-- Building a major feature or system
-- The scope is unclear or large
-- Multiple team members need alignment
-- The work affects game pillars or core loop
-- You need documentation for future reference
-
----
+Quick-Flow:
+Idea → Quick-Prototype → Quick-Dev → Done
+```
 
 ## Checklists
 
-### Quick-Prototype Checklist
-
-**Before:**
-
+**Quick-Prototype:**
 - [ ] Prototype scope defined
 - [ ] Success criteria established (2-3 items)
-
-**During:**
-
 - [ ] Minimum viable code written
 - [ ] Placeholder assets used
-- [ ] Core functionality testable
-
-**After:**
-
 - [ ] Each criterion evaluated
 - [ ] Decision made (develop/iterate/archive)
 
-### Quick-Dev Checklist
-
-**Before:**
-
+**Quick-Dev:**
 - [ ] Context loaded (spec, prototype, or guidance)
 - [ ] Files to modify identified
-- [ ] Patterns understood
-
-**During:**
-
 - [ ] All tasks completed
 - [ ] No allocations in hot paths
-- [ ] Frame rate maintained
-
-**After:**
-
 - [ ] Game runs without errors
-- [ ] Feature works as specified
 - [ ] Manual playtest completed
 
----
+## Tips
 
-## Tips for Success
-
-### 1. Timebox Prototypes
-
-Set a limit (e.g., 2 hours) for prototyping. If it's not working by then, step back and reconsider.
-
-### 2. Embrace Programmer Art
-
-Prototypes don't need to look good. Focus on feel, not visuals.
-
-### 3. Test on Target Hardware
-
-What feels right on your dev machine might not feel right on target platform.
-
-### 4. Document Learnings
-
-Even failed prototypes teach something. Note what you learned.
-
-### 5. Know When to Graduate
-
-If quick-dev keeps expanding scope, stop and create proper stories.
-
----
-
-## Next Steps
-
-- **[Workflows Guide](/docs/reference/workflows/bmgd-workflows.md)** - Full workflow reference
-- **[Agents Guide](/docs/explanation/game-dev/agents.md)** - Agent capabilities
-- **[Quick Start Guide](/docs/tutorials/getting-started/quick-start-bmgd.md)** - Getting started with BMGD
+- **Timebox prototypes** — Set a limit (e.g., 2 hours). If it's not working, step back
+- **Embrace programmer art** — Focus on feel, not visuals
+- **Test on target hardware** — What feels right on dev machine might not on target
+- **Document learnings** — Even failed prototypes teach something
+- **Know when to graduate** — If quick-dev keeps expanding scope, create proper stories

docs/how-to/workflows/conduct-research.md

@@ -3,11 +3,8 @@ title: "How to Conduct Research"
 description: How to conduct market, technical, and competitive research using BMad Method
 ---
 
-
 Use the `research` workflow to perform comprehensive multi-type research for validating ideas, understanding markets, and making informed decisions.
 
----
-
 ## When to Use This
 
 - Need market viability validation
@@ -17,14 +14,10 @@ Use the `research` workflow to perform comprehensive multi-type research for val
 - Understanding domain or industry
 - Need deeper AI-assisted research
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - Analyst agent available
-
----
+:::
 
 ## Steps
 
@@ -42,14 +35,14 @@ Start a fresh chat and load the Analyst agent.
 
 Select the type of research you need:
 
-| Type            | Purpose                                                | Use When                            |
-| --------------- | ------------------------------------------------------ | ----------------------------------- |
-| **market**      | TAM/SAM/SOM, competitive analysis                      | Need market viability validation    |
-| **technical**   | Technology evaluation, ADRs                            | Choosing frameworks/platforms       |
-| **competitive** | Deep competitor analysis                               | Understanding competitive landscape |
-| **user**        | Customer insights, personas, JTBD                      | Need user understanding             |
-| **domain**      | Industry deep dives, trends                            | Understanding domain/industry       |
-| **deep_prompt** | Generate AI research prompts (ChatGPT, Claude, Gemini) | Need deeper AI-assisted research    |
+| Type | Purpose | Use When |
+|------|---------|----------|
+| **market** | TAM/SAM/SOM, competitive analysis | Need market viability validation |
+| **technical** | Technology evaluation, ADRs | Choosing frameworks/platforms |
+| **competitive** | Deep competitor analysis | Understanding competitive landscape |
+| **user** | Customer insights, personas, JTBD | Need user understanding |
+| **domain** | Industry deep dives, trends | Understanding domain/industry |
+| **deep_prompt** | Generate AI research prompts | Need deeper AI-assisted research |
 
 ### 4. Provide Context
 
@@ -63,38 +56,24 @@ Give the agent details about what you're researching:
 
 Choose your depth level:
 
-- **Quick** - Fast overview
-- **Standard** - Balanced depth
-- **Comprehensive** - Deep analysis
-
----
+- **Quick** — Fast overview
+- **Standard** — Balanced depth
+- **Comprehensive** — Deep analysis
 
 ## What You Get
 
-### Market Research Example
+Research output varies by type:
 
-```
-TAM: $50B
-SAM: $5B
-SOM: $50M
+**Market Research:**
+- TAM/SAM/SOM analysis
+- Top competitors
+- Positioning recommendation
 
-Top Competitors:
-- Asana
-- Monday
-- etc.
-
-Positioning Recommendation: ...
-```
-
-### Technical Research Example
-
-Technology evaluation with:
+**Technical Research:**
 - Comparison matrix
 - Trade-off analysis
 - Recommendations with rationale
 
----
-
 ## Key Features
 
 - Real-time web research
@@ -102,29 +81,17 @@ Technology evaluation with:
 - Platform-specific optimization for deep_prompt type
 - Configurable research depth
 
----
+## Tips
+
+- **Use market research early** — Validates new product ideas
+- **Technical research helps architecture** — Inform ADRs with data
+- **Competitive research informs positioning** — Differentiate your product
+- **Domain research for specialized industries** — Fintech, healthcare, etc.
 
 ## Next Steps
 
 After research:
 
-1. **Product Brief** - Capture strategic vision informed by research
-2. **PRD** - Use findings as context for requirements
-3. **Architecture** - Use technical research in ADRs
-
----
-
-## Tips
-
-- Use market research early for new products
-- Technical research helps with architecture decisions
-- Competitive research informs positioning
-- Domain research is valuable for specialized industries
-
----
-
-## Related
-
-- [Run Brainstorming Session](/docs/how-to/workflows/run-brainstorming-session.md) - Explore ideas before research
-- [Create Product Brief](/docs/how-to/workflows/create-product-brief.md) - Capture strategic vision
-- [Create PRD](/docs/how-to/workflows/create-prd.md) - Move to formal planning
+1. **Product Brief** — Capture strategic vision informed by research
+2. **PRD** — Use findings as context for requirements
+3. **Architecture** — Use technical research in ADRs

docs/how-to/workflows/create-architecture.md

@@ -3,11 +3,8 @@ title: "How to Create Architecture"
 description: How to create system architecture using the BMad Method
 ---
 
-
 Use the `architecture` workflow to make technical decisions explicit and prevent agent conflicts during implementation.
 
----
-
 ## When to Use This
 
 - Multi-epic projects (BMad Method, Enterprise)
@@ -16,23 +13,17 @@ Use the `architecture` workflow to make technical decisions explicit and prevent
 - Integration complexity exists
 - Technology choices need alignment
 
----
-
 ## When to Skip This
 
 - Quick Flow (simple changes)
 - BMad Method Simple with straightforward tech stack
 - Single epic with clear technical approach
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - Architect agent available
 - PRD completed
-
----
+:::
 
 ## Steps
 
@@ -63,25 +54,21 @@ Work with the agent to create Architecture Decision Records (ADRs) for significa
 
 The agent produces a decision-focused architecture document.
 
----
-
 ## What You Get
 
 An `architecture.md` document containing:
 
-1. **Architecture Overview** - System context, principles, style
-2. **System Architecture** - High-level diagram, component interactions
-3. **Data Architecture** - Database design, state management, caching
-4. **API Architecture** - API style (REST/GraphQL/gRPC), auth, versioning
-5. **Frontend Architecture** - Framework, state management, components
-6. **Integration Architecture** - Third-party integrations, messaging
-7. **Security Architecture** - Auth/authorization, data protection
-8. **Deployment Architecture** - CI/CD, environments, monitoring
-9. **ADRs** - Key decisions with context, options, rationale
-10. **FR/NFR-Specific Guidance** - Technical approach per requirement
-11. **Standards and Conventions** - Directory structure, naming, testing
-
----
+1. **Architecture Overview** — System context, principles, style
+2. **System Architecture** — High-level diagram, component interactions
+3. **Data Architecture** — Database design, state management, caching
+4. **API Architecture** — API style (REST/GraphQL/gRPC), auth, versioning
+5. **Frontend Architecture** — Framework, state management, components
+6. **Integration Architecture** — Third-party integrations, messaging
+7. **Security Architecture** — Auth/authorization, data protection
+8. **Deployment Architecture** — CI/CD, environments, monitoring
+9. **ADRs** — Key decisions with context, options, rationale
+10. **FR/NFR-Specific Guidance** — Technical approach per requirement
+11. **Standards and Conventions** — Directory structure, naming, testing
 
 ## ADR Format
 
@@ -110,8 +97,6 @@ An `architecture.md` document containing:
 - Mitigation: Use DataLoader for batching
 ```
 
----
-
 ## Example
 
 E-commerce platform produces:
@@ -119,29 +104,16 @@ E-commerce platform produces:
 - ADRs explaining each choice
 - FR/NFR-specific implementation guidance
 
----
-
 ## Tips
 
-- Focus on decisions that prevent agent conflicts
-- Use ADRs for every significant technology choice
-- Keep it practical - don't over-architect
-- Architecture is living - update as you learn
-
----
+- **Focus on decisions that prevent conflicts** — Multiple agents need alignment
+- **Use ADRs for every significant choice** — Document the "why"
+- **Keep it practical** — Don't over-architect
+- **Architecture is living** — Update as you learn
 
 ## Next Steps
 
 After architecture:
 
-1. **Create Epics and Stories** - Work breakdown informed by architecture
-2. **Implementation Readiness** - Gate check before Phase 4
-
----
-
-## Related
-
-- [Create PRD](/docs/how-to/workflows/create-prd.md) - Requirements before architecture
-- [Create Epics and Stories](/docs/how-to/workflows/create-epics-and-stories.md) - Next step
-- [Run Implementation Readiness](/docs/how-to/workflows/run-implementation-readiness.md) - Gate check
-- [Why Solutioning Matters](/docs/explanation/architecture/why-solutioning-matters.md)
+1. **Create Epics and Stories** — Work breakdown informed by architecture
+2. **Implementation Readiness** — Gate check before Phase 4

docs/how-to/workflows/create-epics-and-stories.md

@@ -3,38 +3,29 @@ title: "How to Create Epics and Stories"
 description: How to break PRD requirements into epics and stories using BMad Method
 ---
 
-
 Use the `create-epics-and-stories` workflow to transform PRD requirements into bite-sized stories organized into deliverable epics.
 
----
-
 ## When to Use This
 
 - After architecture workflow completes
 - When PRD contains FRs/NFRs ready for implementation breakdown
 - Before implementation-readiness gate check
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - PM agent available
 - PRD completed
 - Architecture completed
-
----
+:::
 
 ## Why After Architecture?
 
 This workflow runs AFTER architecture because:
 
-1. **Informed Story Sizing** - Architecture decisions affect story complexity
-2. **Dependency Awareness** - Architecture reveals technical dependencies
-3. **Technical Feasibility** - Stories can be properly scoped knowing the tech stack
-4. **Consistency** - All stories align with documented architectural patterns
-
----
+1. **Informed Story Sizing** — Architecture decisions affect story complexity
+2. **Dependency Awareness** — Architecture reveals technical dependencies
+3. **Technical Feasibility** — Stories can be properly scoped knowing the tech stack
+4. **Consistency** — All stories align with documented architectural patterns
 
 ## Steps
 
@@ -67,8 +58,6 @@ Ensure each story has:
 - Identified dependencies
 - Technical notes from architecture
 
----
-
 ## What You Get
 
 Epic files (one per epic) containing:
@@ -79,8 +68,6 @@ Epic files (one per epic) containing:
 4. **Dependencies between stories**
 5. **Technical notes** referencing architecture decisions
 
----
-
 ## Example
 
 E-commerce PRD with FR-001 (User Registration), FR-002 (Product Catalog) produces:
@@ -98,39 +85,25 @@ E-commerce PRD with FR-001 (User Registration), FR-002 (Product Catalog) produce
 
 Each story references relevant ADRs from architecture.
 
----
-
 ## Story Priority Levels
 
 | Priority | Meaning |
 |----------|---------|
-| **P0** | Critical - Must have for MVP |
-| **P1** | High - Important for release |
-| **P2** | Medium - Nice to have |
-| **P3** | Low - Future consideration |
-
----
+| **P0** | Critical — Must have for MVP |
+| **P1** | High — Important for release |
+| **P2** | Medium — Nice to have |
+| **P3** | Low — Future consideration |
 
 ## Tips
 
-- Keep stories small enough to complete in a session
-- Ensure acceptance criteria are testable
-- Document dependencies clearly
-- Reference architecture decisions in technical notes
-
----
+- **Keep stories small** — Complete in a single session
+- **Make criteria testable** — Acceptance criteria should be verifiable
+- **Document dependencies clearly** — Know what blocks what
+- **Reference architecture** — Include ADR references in technical notes
 
 ## Next Steps
 
 After creating epics and stories:
 
-1. **Implementation Readiness** - Validate alignment before Phase 4
-2. **Sprint Planning** - Organize work for implementation
-
----
-
-## Related
-
-- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Do this first
-- [Run Implementation Readiness](/docs/how-to/workflows/run-implementation-readiness.md) - Gate check
-- [Run Sprint Planning](/docs/how-to/workflows/run-sprint-planning.md) - Start implementation
+1. **Implementation Readiness** — Validate alignment before Phase 4
+2. **Sprint Planning** — Organize work for implementation

docs/how-to/workflows/create-prd.md

@@ -3,11 +3,8 @@ title: "How to Create a PRD"
 description: How to create a Product Requirements Document using the BMad Method
 ---
 
-
 Use the `prd` workflow to create a strategic Product Requirements Document with Functional Requirements (FRs) and Non-Functional Requirements (NFRs).
 
----
-
 ## When to Use This
 
 - Medium to large feature sets
@@ -16,15 +13,11 @@ Use the `prd` workflow to create a strategic Product Requirements Document with
 - Multiple system integrations
 - Phased delivery required
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - PM agent available
 - Optional: Product brief from Phase 1
-
----
+:::
 
 ## Steps
 
@@ -48,15 +41,13 @@ The workflow will:
 ### 4. Define Requirements
 
 Work with the agent to define:
-- Functional Requirements (FRs) - What the system should do
-- Non-Functional Requirements (NFRs) - How well it should do it
+- Functional Requirements (FRs) — What the system should do
+- Non-Functional Requirements (NFRs) — How well it should do it
 
 ### 5. Review the PRD
 
 The agent produces a comprehensive PRD scaled to your project.
 
----
-
 ## What You Get
 
 A `PRD.md` document containing:
@@ -69,8 +60,6 @@ A `PRD.md` document containing:
 - Success metrics
 - Risks and assumptions
 
----
-
 ## Scale-Adaptive Structure
 
 The PRD adapts to your project complexity:
@@ -81,50 +70,22 @@ The PRD adapts to your project complexity:
 | **Standard** | 20-30 | Comprehensive FRs/NFRs, thorough analysis |
 | **Comprehensive** | 30-50+ | Extensive FRs/NFRs, multi-phase, stakeholder analysis |
 
----
-
-## V6 Improvement
-
-In V6, the PRD focuses on **WHAT** to build (requirements). Epic and Stories are created **AFTER** architecture via the `create-epics-and-stories` workflow for better quality.
-
----
-
 ## Example
 
 E-commerce checkout → PRD with:
 - 15 FRs (user account, cart management, payment flow)
 - 8 NFRs (performance, security, scalability)
 
----
+## Tips
 
-## Best Practices
-
-### 1. Do Product Brief First
-
-Run product-brief from Phase 1 to kickstart the PRD for better results.
-
-### 2. Focus on "What" Not "How"
-
-Planning defines **what** to build and **why**. Leave **how** (technical design) to Phase 3 (Solutioning).
-
-### 3. Document-Project First for Brownfield
-
-Always run `document-project` before planning brownfield projects. AI agents need existing codebase context.
-
----
+- **Do Product Brief first** — Run product-brief from Phase 1 for better results
+- **Focus on "What" not "How"** — Planning defines what to build and why. Leave how (technical design) to Phase 3
+- **Document-Project first for Brownfield** — Always run `document-project` before planning brownfield projects. AI agents need existing codebase context
 
 ## Next Steps
 
 After PRD:
 
-1. **Create UX Design** (optional) - If UX is critical
-2. **Create Architecture** - Technical design
-3. **Create Epics and Stories** - After architecture
-
----
-
-## Related
-
-- [Create Product Brief](/docs/how-to/workflows/create-product-brief.md) - Input for PRD
-- [Create UX Design](/docs/how-to/workflows/create-ux-design.md) - Optional UX workflow
-- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Next step after PRD
+1. **Create UX Design** (optional) — If UX is critical
+2. **Create Architecture** — Technical design
+3. **Create Epics and Stories** — After architecture

docs/how-to/workflows/create-product-brief.md

@@ -3,11 +3,8 @@ title: "How to Create a Product Brief"
 description: How to create a product brief using the BMad Method
 ---
 
-
 Use the `product-brief` workflow to define product vision and strategy through an interactive process.
 
----
-
 ## When to Use This
 
 - Starting new product or major feature initiative
@@ -15,15 +12,11 @@ Use the `product-brief` workflow to define product vision and strategy through a
 - Transitioning from exploration to strategy
 - Need executive-level product documentation
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - Analyst agent available
 - Optional: Research documents from previous workflows
-
----
+:::
 
 ## Steps
 
@@ -50,22 +43,18 @@ The workflow guides you through strategic product vision definition:
 
 The agent will draft sections and let you refine them interactively.
 
----
-
 ## What You Get
 
 The `product-brief.md` document includes:
 
-- **Executive summary** - High-level overview
-- **Problem statement** - With evidence
-- **Proposed solution** - And differentiators
-- **Target users** - Segmented
-- **MVP scope** - Ruthlessly defined
-- **Financial impact** - And ROI
-- **Strategic alignment** - With business goals
-- **Risks and open questions** - Documented upfront
-
----
+- **Executive summary** — High-level overview
+- **Problem statement** — With evidence
+- **Proposed solution** — And differentiators
+- **Target users** — Segmented
+- **MVP scope** — Ruthlessly defined
+- **Financial impact** — And ROI
+- **Strategic alignment** — With business goals
+- **Risks and open questions** — Documented upfront
 
 ## Integration with Other Workflows
 
@@ -79,11 +68,9 @@ The product brief feeds directly into the PRD workflow:
 
 Planning workflows automatically load the product brief if it exists.
 
----
-
 ## Common Patterns
 
-### Greenfield Software (Full Analysis)
+**Greenfield Software (Full Analysis):**
 
 ```
 1. brainstorm-project - explore approaches
@@ -92,26 +79,16 @@ Planning workflows automatically load the product brief if it exists.
 4. → Phase 2: prd
 ```
 
-### Skip Analysis (Clear Requirements)
+**Skip Analysis (Clear Requirements):**
 
 ```
 → Phase 2: prd or tech-spec directly
 ```
 
----
-
 ## Tips
 
-- Be specific about the problem you're solving
-- Ruthlessly prioritize MVP scope
-- Document assumptions and risks
-- Use research findings as evidence
-- This is recommended for greenfield projects
-
----
-
-## Related
-
-- [Run Brainstorming Session](/docs/how-to/workflows/run-brainstorming-session.md) - Explore ideas first
-- [Conduct Research](/docs/how-to/workflows/conduct-research.md) - Validate ideas
-- [Create PRD](/docs/how-to/workflows/create-prd.md) - Next step after product brief
+- **Be specific about the problem** — Vague problems lead to vague solutions
+- **Ruthlessly prioritize MVP scope** — Less is more
+- **Document assumptions and risks** — Surface unknowns early
+- **Use research findings as evidence** — Back up claims with data
+- **Recommended for greenfield projects** — Sets strategic foundation

docs/how-to/workflows/create-story.md

@@ -3,27 +3,20 @@ title: "How to Create a Story"
 description: How to create implementation-ready stories from epic backlog
 ---
 
-
 Use the `create-story` workflow to prepare the next story from the epic backlog for implementation.
 
----
-
 ## When to Use This
 
 - Before implementing each story
 - When moving to the next story in an epic
 - After sprint-planning has been run
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - SM (Scrum Master) agent available
 - Sprint-status.yaml created by sprint-planning
 - Architecture and PRD available for context
-
----
+:::
 
 ## Steps
 
@@ -48,8 +41,6 @@ The agent will:
 
 The agent creates a comprehensive story file ready for development.
 
----
-
 ## What You Get
 
 A `story-[slug].md` file containing:
@@ -61,23 +52,18 @@ A `story-[slug].md` file containing:
 - Dependencies on other stories
 - Definition of Done
 
----
-
 ## Story Content Sources
 
 The create-story workflow pulls from:
 
-- **PRD** - Requirements and acceptance criteria
-- **Architecture** - Technical approach and ADRs
-- **Epic file** - Story context and dependencies
-- **Existing code** - Patterns to follow (brownfield)
-
----
+- **PRD** — Requirements and acceptance criteria
+- **Architecture** — Technical approach and ADRs
+- **Epic file** — Story context and dependencies
+- **Existing code** — Patterns to follow (brownfield)
 
 ## Example Output
 
 ```markdown
-
 ## Objective
 Implement email verification flow for new user registrations.
 
@@ -93,7 +79,7 @@ Implement email verification flow for new user registrations.
 - Follow existing email template patterns in /templates
 
 ## Dependencies
-- Story 1.1 (User Registration) - DONE ✅
+- Story 1.1 (User Registration) - DONE
 
 ## Definition of Done
 - All acceptance criteria pass
@@ -101,19 +87,16 @@ Implement email verification flow for new user registrations.
 - Code review approved
 ```
 
----
-
 ## Tips
 
-- Complete one story before creating the next
-- Ensure dependencies are marked DONE before starting
-- Review technical notes for architecture alignment
-- Use the story file as context for dev-story
+- **Complete one story before creating the next** — Focus on finishing
+- **Ensure dependencies are DONE** — Don't start blocked stories
+- **Review technical notes** — Align with architecture
+- **Use the story file as context** — Pass to dev-story workflow
 
----
+## Next Steps
 
-## Related
+After creating a story:
 
-- [Run Sprint Planning](/docs/how-to/workflows/run-sprint-planning.md) - Initialize tracking
-- [Implement Story](/docs/how-to/workflows/implement-story.md) - Next step
-- [Run Code Review](/docs/how-to/workflows/run-code-review.md) - After implementation
+1. **Implement Story** — Run dev-story with the DEV agent
+2. **Code Review** — Run code-review after implementation

docs/how-to/workflows/create-ux-design.md

@@ -3,11 +3,8 @@ title: "How to Create a UX Design"
 description: How to create UX specifications using the BMad Method
 ---
 
-
 Use the `create-ux-design` workflow to create UX specifications for projects where user experience is a primary differentiator.
 
----
-
 ## When to Use This
 
 - UX is primary competitive advantage
@@ -16,8 +13,6 @@ Use the `create-ux-design` workflow to create UX specifications for projects whe
 - Design system creation
 - Accessibility-critical experiences
 
----
-
 ## When to Skip This
 
 - Simple CRUD interfaces
@@ -25,15 +20,11 @@ Use the `create-ux-design` workflow to create UX specifications for projects whe
 - Changes to existing screens you're happy with
 - Quick Flow projects
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - UX Designer agent available
 - PRD completed
-
----
+:::
 
 ## Steps
 
@@ -58,17 +49,15 @@ Point the agent to your PRD and describe:
 
 The workflow uses a collaborative approach:
 
-1. **Visual exploration** - Generate multiple options
-2. **Informed decisions** - Evaluate with user needs
-3. **Collaborative design** - Refine iteratively
-4. **Living documentation** - Evolves with project
+1. **Visual exploration** — Generate multiple options
+2. **Informed decisions** — Evaluate with user needs
+3. **Collaborative design** — Refine iteratively
+4. **Living documentation** — Evolves with project
 
 ### 5. Review the UX Spec
 
 The agent produces comprehensive UX documentation.
 
----
-
 ## What You Get
 
 The `ux-spec.md` document includes:
@@ -79,8 +68,6 @@ The `ux-spec.md` document includes:
 - Design system (components, patterns, tokens)
 - Epic breakdown (UX stories)
 
----
-
 ## Example
 
 Dashboard redesign produces:
@@ -90,8 +77,6 @@ Dashboard redesign produces:
 - Responsive grid
 - 3 epics (Layout, Visualization, Accessibility)
 
----
-
 ## Integration
 
 The UX spec feeds into:
@@ -99,19 +84,17 @@ The UX spec feeds into:
 - Epic and story creation
 - Architecture decisions (Phase 3)
 
----
-
 ## Tips
 
-- Focus on user problems, not solutions first
-- Generate multiple options before deciding
-- Consider accessibility from the start
-- Document component reusability
+- **Focus on user problems first** — Solutions come second
+- **Generate multiple options** — Don't settle on the first idea
+- **Consider accessibility from the start** — Not an afterthought
+- **Document component reusability** — Build a system, not just screens
 
----
+## Next Steps
 
-## Related
+After UX design:
 
-- [Create PRD](/docs/how-to/workflows/create-prd.md) - Create requirements first
-- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Technical design
-- [Create Epics and Stories](/docs/how-to/workflows/create-epics-and-stories.md) - Work breakdown
+1. **Update PRD** — Incorporate UX findings
+2. **Create Architecture** — Technical design informed by UX
+3. **Create Epics and Stories** — Include UX-specific stories

docs/how-to/workflows/implement-story.md

@@ -3,27 +3,20 @@ title: "How to Implement a Story"
 description: How to implement a story using the dev-story workflow
 ---
 
-
 Use the `dev-story` workflow to implement a story with tests following the architecture and conventions.
 
----
-
 ## When to Use This
 
 - After create-story has prepared the story file
 - When ready to write code for a story
 - Story dependencies are marked DONE
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - DEV agent available
 - Story file created by create-story
 - Architecture and tech-spec available for context
-
----
+:::
 
 ## Steps
 
@@ -53,75 +46,52 @@ The DEV agent:
 
 Work with the agent until all acceptance criteria are met.
 
----
-
 ## What Happens
 
 The dev-story workflow:
 
-1. **Reads context** - Story file, architecture, existing patterns
-2. **Plans implementation** - Identifies files to create/modify
-3. **Writes code** - Following conventions and patterns
-4. **Writes tests** - Unit, integration, or E2E as appropriate
-5. **Validates** - Runs tests and checks acceptance criteria
-
----
+1. **Reads context** — Story file, architecture, existing patterns
+2. **Plans implementation** — Identifies files to create/modify
+3. **Writes code** — Following conventions and patterns
+4. **Writes tests** — Unit, integration, or E2E as appropriate
+5. **Validates** — Runs tests and checks acceptance criteria
 
 ## Key Principles
 
-### One Story at a Time
+**One Story at a Time** — Complete each story's full lifecycle before starting the next. This prevents context switching and ensures quality.
 
-Complete each story's full lifecycle before starting the next. This prevents context switching and ensures quality.
+**Follow Architecture** — The DEV agent references ADRs for technology decisions, standards for naming and structure, and existing patterns in the codebase.
 
-### Follow Architecture
-
-The DEV agent references:
-- ADRs for technology decisions
-- Standards for naming and structure
-- Existing patterns in the codebase
-
-### Write Tests
-
-Every story includes appropriate tests:
-- Unit tests for business logic
-- Integration tests for API endpoints
-- E2E tests for critical flows
-
----
+**Write Tests** — Every story includes appropriate tests: unit tests for business logic, integration tests for API endpoints, E2E tests for critical flows.
 
 ## After Implementation
 
-1. **Update sprint-status.yaml** - Mark story as READY FOR REVIEW
-2. **Run code-review** - Quality assurance
-3. **Address feedback** - If code review finds issues
-4. **Mark DONE** - After code review passes
-
----
+1. **Update sprint-status.yaml** — Mark story as READY FOR REVIEW
+2. **Run code-review** — Quality assurance
+3. **Address feedback** — If code review finds issues
+4. **Mark DONE** — After code review passes
 
 ## Tips
 
-- Keep the story file open for reference
-- Ask the agent to explain decisions
-- Run tests frequently during implementation
-- Don't skip tests for "simple" changes
-
----
+- **Keep the story file open** — Reference it during implementation
+- **Ask the agent to explain decisions** — Understand the approach
+- **Run tests frequently** — Catch issues early
+- **Don't skip tests** — Even for "simple" changes
 
 ## Troubleshooting
 
-**Q: Story needs significant changes mid-implementation?**
-A: Run `correct-course` to analyze impact and route appropriately.
+**Story needs significant changes mid-implementation?**
+Run `correct-course` to analyze impact and route appropriately.
 
-**Q: Can I work on multiple stories in parallel?**
-A: Not recommended. Complete one story's full lifecycle first.
+**Can I work on multiple stories in parallel?**
+Not recommended. Complete one story's full lifecycle first.
 
-**Q: What if implementation reveals the story is too large?**
-A: Split the story and document the change.
+**What if implementation reveals the story is too large?**
+Split the story and document the change.
 
----
+## Next Steps
 
-## Related
+After implementing a story:
 
-- [Create Story](/docs/how-to/workflows/create-story.md) - Prepare the story first
-- [Run Code Review](/docs/how-to/workflows/run-code-review.md) - After implementation
-- [Run Sprint Planning](/docs/how-to/workflows/run-sprint-planning.md) - Sprint organization
+1. **Code Review** — Run code-review with the DEV agent
+2. **Create Next Story** — Run create-story with the SM agent

docs/how-to/workflows/quick-spec.md

@@ -3,10 +3,7 @@ title: "How to Use Quick Spec"
 description: How to create a technical specification using Quick Spec workflow
 ---
 
-
-Use the `tech-spec` workflow for Quick Flow projects to go directly from idea to implementation-ready specification.
-
----
+Use the `quick-spec` workflow for Quick Flow projects to go directly from idea to implementation-ready specification.
 
 ## When to Use This
 
@@ -16,15 +13,11 @@ Use the `tech-spec` workflow for Quick Flow projects to go directly from idea to
 - Adding to existing brownfield codebase
 - Quick Flow track projects
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - PM agent or Quick Flow Solo Dev agent available
 - Project directory (can be empty for greenfield)
-
----
+:::
 
 ## Steps
 
@@ -63,12 +56,9 @@ For brownfield projects, the agent will:
 
 The agent generates a comprehensive tech-spec with ready-to-implement stories.
 
----
-
 ## What You Get
 
-### tech-spec.md
-
+**tech-spec.md:**
 - Problem statement and solution
 - Detected framework versions and dependencies
 - Brownfield code patterns (if applicable)
@@ -76,18 +66,11 @@ The agent generates a comprehensive tech-spec with ready-to-implement stories.
 - Specific file paths to modify
 - Complete implementation guidance
 
-### Story Files
+**Story Files:**
+- Single changes: `story-[slug].md`
+- Small features: `epics.md` + `story-[epic-slug]-1.md`, etc.
 
-For single changes:
-- `story-[slug].md` - Single user story ready for development
-
-For small features:
-- `epics.md` - Epic organization
-- `story-[epic-slug]-1.md`, `story-[epic-slug]-2.md`, etc.
-
----
-
-## Example: Bug Fix (Single Change)
+## Example: Bug Fix
 
 **You:** "I want to fix the login validation bug that allows empty passwords"
 
@@ -99,11 +82,7 @@ For small features:
 5. Generates tech-spec.md with specific file paths
 6. Creates story-login-fix.md
 
-**Total time:** 15-30 minutes (mostly implementation)
-
----
-
-## Example: Small Feature (Multi-Story)
+## Example: Small Feature
 
 **You:** "I want to add OAuth social login (Google, GitHub)"
 
@@ -118,10 +97,6 @@ For small features:
    - story-oauth-1.md (Backend OAuth setup)
    - story-oauth-2.md (Frontend login buttons)
 
-**Total time:** 1-3 hours (mostly implementation)
-
----
-
 ## Implementing After Tech Spec
 
 ```bash
@@ -133,27 +108,15 @@ For small features:
 # Then: Load DEV agent and run dev-story for each story
 ```
 
----
-
 ## Tips
 
-### Be Specific in Discovery
+- **Be specific in discovery** — "Fix email validation in UserService to allow plus-addressing" beats "Fix validation bug"
+- **Trust convention detection** — If it detects your patterns correctly, say yes! It's faster than establishing new conventions
+- **Keep single changes atomic** — If your "single change" needs 3+ files, it might be a multi-story feature. Let the workflow guide you
 
-- ✅ "Fix email validation in UserService to allow plus-addressing"
-- ❌ "Fix validation bug"
+## Next Steps
 
-### Trust Convention Detection
+After tech spec:
 
-If it detects your patterns correctly, say yes! It's faster than establishing new conventions.
-
-### Keep Single Changes Atomic
-
-If your "single change" needs 3+ files, it might be a multi-story feature. Let the workflow guide you.
-
----
-
-## Related
-
-- [Quick Flow](/docs/explanation/features/quick-flow.md) - Understanding Quick Spec Flow
-- [Implement Story](/docs/how-to/workflows/implement-story.md) - After tech spec
-- [Create PRD](/docs/how-to/workflows/create-prd.md) - For larger projects needing full BMad Method
+1. **Implement Story** — Run dev-story with the DEV agent
+2. **Sprint Planning** — Optional for multi-story features

docs/how-to/workflows/run-atdd.md

@@ -0,0 +1,436 @@
+---
+title: "How to Run ATDD with TEA"
+description: Generate failing acceptance tests before implementation using TEA's ATDD workflow
+---
+
+# How to Run ATDD with TEA
+
+Use TEA's `*atdd` workflow to generate failing acceptance tests BEFORE implementation. This is the TDD (Test-Driven Development) red phase - tests fail first, guide development, then pass.
+
+## When to Use This
+
+- You're about to implement a NEW feature (feature doesn't exist yet)
+- You want to follow TDD workflow (red → green → refactor)
+- You want tests to guide your implementation
+- You're practicing acceptance test-driven development
+
+**Don't use this if:**
+- Feature already exists (use `*automate` instead)
+- You want tests that pass immediately
+
+## Prerequisites
+
+- BMad Method installed
+- TEA agent available
+- Test framework setup complete (run `*framework` if needed)
+- Story or feature defined with acceptance criteria
+
+**Note:** This guide uses Playwright examples. If using Cypress, commands and syntax will differ (e.g., `cy.get()` instead of `page.locator()`).
+
+## Steps
+
+### 1. Load TEA Agent
+
+Start a fresh chat and load TEA:
+
+```
+*tea
+```
+
+### 2. Run the ATDD Workflow
+
+```
+*atdd
+```
+
+### 3. Provide Context
+
+TEA will ask for:
+
+**Story/Feature Details:**
+```
+We're adding a user profile page where users can:
+- View their profile information
+- Edit their name and email
+- Upload a profile picture
+- Save changes with validation
+```
+
+**Acceptance Criteria:**
+```
+Given I'm logged in
+When I navigate to /profile
+Then I see my current name and email
+
+Given I'm on the profile page
+When I click "Edit Profile"
+Then I can modify my name and email
+
+Given I've edited my profile
+When I click "Save"
+Then my changes are persisted
+And I see a success message
+
+Given I upload an invalid file type
+When I try to save
+Then I see an error message
+And changes are not saved
+```
+
+**Reference Documents** (optional):
+- Point to your story file
+- Reference PRD or tech spec
+- Link to test design (if you ran `*test-design` first)
+
+### 4. Specify Test Levels
+
+TEA will ask what test levels to generate:
+
+**Options:**
+- E2E tests (browser-based, full user journey)
+- API tests (backend only, faster)
+- Component tests (UI components in isolation)
+- Mix of levels (see [API Tests First, E2E Later](#api-tests-first-e2e-later) tip)
+
+### Component Testing by Framework
+
+TEA generates component tests using framework-appropriate tools:
+
+| Your Framework | Component Testing Tool                      |
+| -------------- | ------------------------------------------- |
+| **Cypress**    | Cypress Component Testing (*.cy.tsx)        |
+| **Playwright** | Vitest + React Testing Library (*.test.tsx) |
+
+**Example response:**
+```
+Generate:
+- API tests for profile CRUD operations
+- E2E tests for the complete profile editing flow
+- Component tests for ProfileForm validation (if using Cypress or Vitest)
+- Focus on P0 and P1 scenarios
+```
+
+### 5. Review Generated Tests
+
+TEA generates **failing tests** in appropriate directories:
+
+#### API Tests (`tests/api/profile.spec.ts`):
+
+**Vanilla Playwright:**
+```typescript
+import { test, expect } from '@playwright/test';
+
+test.describe('Profile API', () => {
+  test('should fetch user profile', async ({ request }) => {
+    const response = await request.get('/api/profile');
+
+    expect(response.status()).toBe(200);
+    const profile = await response.json();
+    expect(profile).toHaveProperty('name');
+    expect(profile).toHaveProperty('email');
+    expect(profile).toHaveProperty('avatarUrl');
+  });
+
+  test('should update user profile', async ({ request }) => {
+    const response = await request.patch('/api/profile', {
+      data: {
+        name: 'Updated Name',
+        email: 'updated@example.com'
+      }
+    });
+
+    expect(response.status()).toBe(200);
+    const updated = await response.json();
+    expect(updated.name).toBe('Updated Name');
+    expect(updated.email).toBe('updated@example.com');
+  });
+
+  test('should validate email format', async ({ request }) => {
+    const response = await request.patch('/api/profile', {
+      data: {
+        email: 'invalid-email'
+      }
+    });
+
+    expect(response.status()).toBe(400);
+    const error = await response.json();
+    expect(error.message).toContain('Invalid email format');
+  });
+});
+```
+
+**With Playwright Utils:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { expect } from '@playwright/test';
+import { z } from 'zod';
+
+const ProfileSchema = z.object({
+  name: z.string(),
+  email: z.string().email(),
+  avatarUrl: z.string().url()
+});
+
+test.describe('Profile API', () => {
+  test('should fetch user profile', async ({ apiRequest }) => {
+    const { status, body } = await apiRequest({
+      method: 'GET',
+      path: '/api/profile'
+    }).validateSchema(ProfileSchema);  // Chained validation
+
+    expect(status).toBe(200);
+    // Schema already validated, type-safe access
+    expect(body.name).toBeDefined();
+    expect(body.email).toContain('@');
+  });
+
+  test('should update user profile', async ({ apiRequest }) => {
+    const { status, body } = await apiRequest({
+      method: 'PATCH',
+      path: '/api/profile',
+      body: {  
+        name: 'Updated Name',
+        email: 'updated@example.com'
+      }
+    }).validateSchema(ProfileSchema);  // Chained validation
+
+    expect(status).toBe(200);
+    expect(body.name).toBe('Updated Name');
+    expect(body.email).toBe('updated@example.com');
+  });
+
+  test('should validate email format', async ({ apiRequest }) => {
+    const { status, body } = await apiRequest({
+      method: 'PATCH',
+      path: '/api/profile',
+      body: { email: 'invalid-email' }  
+    });
+
+    expect(status).toBe(400);
+    expect(body.message).toContain('Invalid email format');
+  });
+});
+```
+
+**Key Benefits:**
+- Returns `{ status, body }` (cleaner than `response.status()` + `await response.json()`)
+- Automatic schema validation with Zod
+- Type-safe response bodies
+- Automatic retry for 5xx errors
+- Less boilerplate
+
+#### E2E Tests (`tests/e2e/profile.spec.ts`):
+
+```typescript
+import { test, expect } from '@playwright/test';
+
+test('should edit and save profile', async ({ page }) => {
+  // Login first
+  await page.goto('/login');
+  await page.getByLabel('Email').fill('test@example.com');
+  await page.getByLabel('Password').fill('password123');
+  await page.getByRole('button', { name: 'Sign in' }).click();
+
+  // Navigate to profile
+  await page.goto('/profile');
+
+  // Edit profile
+  await page.getByRole('button', { name: 'Edit Profile' }).click();
+  await page.getByLabel('Name').fill('Updated Name');
+  await page.getByRole('button', { name: 'Save' }).click();
+
+  // Verify success
+  await expect(page.getByText('Profile updated')).toBeVisible();
+});
+```
+
+TEA generates additional E2E tests for display, validation errors, etc. based on acceptance criteria.
+
+#### Implementation Checklist
+
+TEA also provides an implementation checklist:
+
+```markdown
+## Implementation Checklist
+
+### Backend
+- [ ] Create `GET /api/profile` endpoint
+- [ ] Create `PATCH /api/profile` endpoint
+- [ ] Add email validation middleware
+- [ ] Add profile picture upload handling
+- [ ] Write API unit tests
+
+### Frontend
+- [ ] Create ProfilePage component
+- [ ] Implement profile form with validation
+- [ ] Add file upload for avatar
+- [ ] Handle API errors gracefully
+- [ ] Add loading states
+
+### Tests
+- [x] API tests generated (failing)
+- [x] E2E tests generated (failing)
+- [ ] Run tests after implementation (should pass)
+```
+
+### 6. Verify Tests Fail
+
+This is the TDD red phase - tests MUST fail before implementation.
+
+**For Playwright:**
+```bash
+npx playwright test
+```
+
+**For Cypress:**
+```bash
+npx cypress run
+```
+
+Expected output:
+```
+Running 6 tests using 1 worker
+
+  ✗ tests/api/profile.spec.ts:3:3 › should fetch user profile
+    Error: expect(received).toBe(expected)
+    Expected: 200
+    Received: 404
+
+  ✗ tests/e2e/profile.spec.ts:10:3 › should display current profile information
+    Error: page.goto: net::ERR_ABORTED
+```
+
+**All tests should fail!** This confirms:
+- Feature doesn't exist yet
+- Tests will guide implementation
+- You have clear success criteria
+
+### 7. Implement the Feature
+
+Now implement the feature following the test guidance:
+
+1. Start with API tests (backend first)
+2. Make API tests pass
+3. Move to E2E tests (frontend)
+4. Make E2E tests pass
+5. Refactor with confidence (tests protect you)
+
+### 8. Verify Tests Pass
+
+After implementation, run your test suite.
+
+**For Playwright:**
+```bash
+npx playwright test
+```
+
+**For Cypress:**
+```bash
+npx cypress run
+```
+
+Expected output:
+```
+Running 6 tests using 1 worker
+
+  ✓ tests/api/profile.spec.ts:3:3 › should fetch user profile (850ms)
+  ✓ tests/api/profile.spec.ts:15:3 › should update user profile (1.2s)
+  ✓ tests/api/profile.spec.ts:30:3 › should validate email format (650ms)
+  ✓ tests/e2e/profile.spec.ts:10:3 › should display current profile (2.1s)
+  ✓ tests/e2e/profile.spec.ts:18:3 › should edit and save profile (3.2s)
+  ✓ tests/e2e/profile.spec.ts:35:3 › should show validation error (1.8s)
+
+  6 passed (9.8s)
+```
+
+**Green!** You've completed the TDD cycle: red → green → refactor.
+
+## What You Get
+
+### Failing Tests
+- API tests for backend endpoints
+- E2E tests for user workflows
+- Component tests (if requested)
+- All tests fail initially (red phase)
+
+### Implementation Guidance
+- Clear checklist of what to build
+- Acceptance criteria translated to assertions
+- Edge cases and error scenarios identified
+
+### TDD Workflow Support
+- Tests guide implementation
+- Confidence to refactor
+- Living documentation of features
+
+## Tips
+
+### Start with Test Design
+
+Run `*test-design` before `*atdd` for better results:
+
+```
+*test-design   # Risk assessment and priorities
+*atdd          # Generate tests based on design
+```
+
+### MCP Enhancements (Optional)
+
+If you have MCP servers configured (`tea_use_mcp_enhancements: true`), TEA can use them during `*atdd`.
+
+**Note:** ATDD is for features that don't exist yet, so recording mode (verify selectors with live UI) only applies if you have skeleton/mockup UI already implemented. For typical ATDD (no UI yet), TEA infers selectors from best practices.
+
+See [Enable MCP Enhancements](/docs/how-to/customization/enable-tea-mcp-enhancements.md) for setup.
+
+### Focus on P0/P1 Scenarios
+
+Don't generate tests for everything at once:
+
+```
+Generate tests for:
+- P0: Critical path (happy path)
+- P1: High value (validation, errors)
+
+Skip P2/P3 for now - add later with *automate
+```
+
+### API Tests First, E2E Later
+
+Recommended order:
+1. Generate API tests with `*atdd`
+2. Implement backend (make API tests pass)
+3. Generate E2E tests with `*atdd` (or `*automate`)
+4. Implement frontend (make E2E tests pass)
+
+This "outside-in" approach is faster and more reliable.
+
+### Keep Tests Deterministic
+
+TEA generates deterministic tests by default:
+- No hard waits (`waitForTimeout`)
+- Network-first patterns (wait for responses)
+- Explicit assertions (no conditionals)
+
+Don't modify these patterns - they prevent flakiness!
+
+## Related Guides
+
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md) - Plan before generating
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md) - Tests for existing features
+- [How to Set Up Test Framework](/docs/how-to/workflows/setup-test-framework.md) - Initial setup
+
+## Understanding the Concepts
+
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - **Why TEA generates quality tests** (foundational)
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Why P0 vs P3 matters
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - What makes tests good
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Avoiding flakiness
+
+## Reference
+
+- [Command: *atdd](/docs/reference/tea/commands.md#atdd) - Full command reference
+- [TEA Configuration](/docs/reference/tea/configuration.md) - MCP and Playwright Utils options
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/workflows/run-automate.md

@@ -0,0 +1,653 @@
+---
+title: "How to Run Automate with TEA"
+description: Expand test automation coverage after implementation using TEA's automate workflow
+---
+
+# How to Run Automate with TEA
+
+Use TEA's `*automate` workflow to generate comprehensive tests for existing features. Unlike `*atdd`, these tests pass immediately because the feature already exists.
+
+## When to Use This
+
+- Feature already exists and works
+- Want to add test coverage to existing code
+- Need tests that pass immediately
+- Expanding existing test suite
+- Adding tests to legacy code
+
+**Don't use this if:**
+- Feature doesn't exist yet (use `*atdd` instead)
+- Want failing tests to guide development (use `*atdd` for TDD)
+
+## Prerequisites
+
+- BMad Method installed
+- TEA agent available
+- Test framework setup complete (run `*framework` if needed)
+- Feature implemented and working
+
+**Note:** This guide uses Playwright examples. If using Cypress, commands and syntax will differ.
+
+## Steps
+
+### 1. Load TEA Agent
+
+Start a fresh chat and load TEA:
+
+```
+*tea
+```
+
+### 2. Run the Automate Workflow
+
+```
+*automate
+```
+
+### 3. Provide Context
+
+TEA will ask for context about what you're testing.
+
+#### Option A: BMad-Integrated Mode (Recommended)
+
+If you have BMad artifacts (stories, test designs, PRDs):
+
+**What are you testing?**
+```
+I'm testing the user profile feature we just implemented.
+Story: story-profile-management.md
+Test Design: test-design-epic-1.md
+```
+
+**Reference documents:**
+- Story file with acceptance criteria
+- Test design document (if available)
+- PRD sections relevant to this feature
+- Tech spec (if available)
+
+**Existing tests:**
+```
+We have basic tests in tests/e2e/profile-view.spec.ts
+Avoid duplicating that coverage
+```
+
+TEA will analyze your artifacts and generate comprehensive tests that:
+- Cover acceptance criteria from the story
+- Follow priorities from test design (P0 → P1 → P2)
+- Avoid duplicating existing tests
+- Include edge cases and error scenarios
+
+#### Option B: Standalone Mode
+
+If you're using TEA Solo or don't have BMad artifacts:
+
+**What are you testing?**
+```
+TodoMVC React application at https://todomvc.com/examples/react/dist/
+Features: Create todos, mark as complete, filter by status, delete todos
+```
+
+**Specific scenarios to cover:**
+```
+- Creating todos (happy path)
+- Marking todos as complete/incomplete
+- Filtering (All, Active, Completed)
+- Deleting todos
+- Edge cases (empty input, long text)
+```
+
+TEA will analyze the application and generate tests based on your description.
+
+### 4. Specify Test Levels
+
+TEA will ask which test levels to generate:
+
+**Options:**
+- **E2E tests** - Full browser-based user workflows
+- **API tests** - Backend endpoint testing (faster, more reliable)
+- **Component tests** - UI component testing in isolation (framework-dependent)
+- **Mix** - Combination of levels (recommended)
+
+**Example response:**
+```
+Generate:
+- API tests for all CRUD operations
+- E2E tests for critical user workflows (P0)
+- Focus on P0 and P1 scenarios
+- Skip P3 (low priority edge cases)
+```
+
+### 5. Review Generated Tests
+
+TEA generates a comprehensive test suite with multiple test levels.
+
+#### API Tests (`tests/api/profile.spec.ts`):
+
+**Vanilla Playwright:**
+```typescript
+import { test, expect } from '@playwright/test';
+
+test.describe('Profile API', () => {
+  let authToken: string;
+
+  test.beforeAll(async ({ request }) => {
+    // Manual auth token fetch
+    const response = await request.post('/api/auth/login', {
+      data: { email: 'test@example.com', password: 'password123' }
+    });
+    const { token } = await response.json();
+    authToken = token;
+  });
+
+  test('should fetch user profile', async ({ request }) => {
+    const response = await request.get('/api/profile', {
+      headers: { Authorization: `Bearer ${authToken}` }
+    });
+
+    expect(response.ok()).toBeTruthy();
+    const profile = await response.json();
+    expect(profile).toMatchObject({
+      id: expect.any(String),
+      name: expect.any(String),
+      email: expect.any(String)
+    });
+  });
+
+  test('should update profile successfully', async ({ request }) => {
+    const response = await request.patch('/api/profile', {
+      headers: { Authorization: `Bearer ${authToken}` },
+      data: {
+        name: 'Updated Name',
+        bio: 'Test bio'
+      }
+    });
+
+    expect(response.ok()).toBeTruthy();
+    const updated = await response.json();
+    expect(updated.name).toBe('Updated Name');
+    expect(updated.bio).toBe('Test bio');
+  });
+
+  test('should validate email format', async ({ request }) => {
+    const response = await request.patch('/api/profile', {
+      headers: { Authorization: `Bearer ${authToken}` },
+      data: { email: 'invalid-email' }
+    });
+
+    expect(response.status()).toBe(400);
+    const error = await response.json();
+    expect(error.message).toContain('Invalid email');
+  });
+
+  test('should require authentication', async ({ request }) => {
+    const response = await request.get('/api/profile');
+    expect(response.status()).toBe(401);
+  });
+});
+```
+
+**With Playwright Utils:**
+```typescript
+import { test as base, expect } from '@playwright/test';
+import { test as apiRequestFixture } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { createAuthFixtures } from '@seontechnologies/playwright-utils/auth-session';
+import { mergeTests } from '@playwright/test';
+import { z } from 'zod';
+
+const ProfileSchema = z.object({
+  id: z.string(),
+  name: z.string(),
+  email: z.string().email()
+});
+
+// Merge API and auth fixtures
+const authFixtureTest = base.extend(createAuthFixtures());
+export const testWithAuth = mergeTests(apiRequestFixture, authFixtureTest);
+
+testWithAuth.describe('Profile API', () => {
+  testWithAuth('should fetch user profile', async ({ apiRequest, authToken }) => {
+    const { status, body } = await apiRequest({
+      method: 'GET',
+      path: '/api/profile',
+      headers: { Authorization: `Bearer ${authToken}` }
+    }).validateSchema(ProfileSchema);  // Chained validation
+
+    expect(status).toBe(200);
+    // Schema already validated, type-safe access
+    expect(body.name).toBeDefined();
+  });
+
+  testWithAuth('should update profile successfully', async ({ apiRequest, authToken }) => {
+    const { status, body } = await apiRequest({
+      method: 'PATCH',
+      path: '/api/profile',
+      body: { name: 'Updated Name', bio: 'Test bio' },  
+      headers: { Authorization: `Bearer ${authToken}` }
+    }).validateSchema(ProfileSchema);  // Chained validation
+
+    expect(status).toBe(200);
+    expect(body.name).toBe('Updated Name');
+  });
+
+  testWithAuth('should validate email format', async ({ apiRequest, authToken }) => {
+    const { status, body } = await apiRequest({
+      method: 'PATCH',
+      path: '/api/profile',
+      body: { email: 'invalid-email' },  
+      headers: { Authorization: `Bearer ${authToken}` }
+    });
+
+    expect(status).toBe(400);
+    expect(body.message).toContain('Invalid email');
+  });
+});
+```
+
+**Key Differences:**
+- `authToken` fixture (persisted, reused across tests)
+- `apiRequest` returns `{ status, body }` (cleaner)
+- Schema validation with Zod (type-safe)
+- Automatic retry for 5xx errors
+- Less boilerplate (no manual `await response.json()` everywhere)
+
+#### E2E Tests (`tests/e2e/profile.spec.ts`):
+
+```typescript
+import { test, expect } from '@playwright/test';
+
+test('should edit profile', async ({ page }) => {
+  // Login
+  await page.goto('/login');
+  await page.getByLabel('Email').fill('test@example.com');
+  await page.getByLabel('Password').fill('password123');
+  await page.getByRole('button', { name: 'Sign in' }).click();
+
+  // Edit profile
+  await page.goto('/profile');
+  await page.getByRole('button', { name: 'Edit Profile' }).click();
+  await page.getByLabel('Name').fill('New Name');
+  await page.getByRole('button', { name: 'Save' }).click();
+
+  // Verify success
+  await expect(page.getByText('Profile updated')).toBeVisible();
+});
+```
+
+TEA generates additional tests for validation, edge cases, etc. based on priorities.
+
+#### Fixtures (`tests/support/fixtures/profile.ts`):
+
+**Vanilla Playwright:**
+```typescript
+import { test as base, Page } from '@playwright/test';
+
+type ProfileFixtures = {
+  authenticatedPage: Page;
+  testProfile: {
+    name: string;
+    email: string;
+    bio: string;
+  };
+};
+
+export const test = base.extend<ProfileFixtures>({
+  authenticatedPage: async ({ page }, use) => {
+    // Manual login flow
+    await page.goto('/login');
+    await page.getByLabel('Email').fill('test@example.com');
+    await page.getByLabel('Password').fill('password123');
+    await page.getByRole('button', { name: 'Sign in' }).click();
+    await page.waitForURL(/\/dashboard/);
+
+    await use(page);
+  },
+
+  testProfile: async ({ request }, use) => {
+    // Static test data
+    const profile = {
+      name: 'Test User',
+      email: 'test@example.com',
+      bio: 'Test bio'
+    };
+
+    await use(profile);
+  }
+});
+```
+
+**With Playwright Utils:**
+```typescript
+import { test as base } from '@playwright/test';
+import { createAuthFixtures } from '@seontechnologies/playwright-utils/auth-session';
+import { mergeTests } from '@playwright/test';
+import { faker } from '@faker-js/faker';
+
+type ProfileFixtures = {
+  testProfile: {
+    name: string;
+    email: string;
+    bio: string;
+  };
+};
+
+// Merge auth fixtures with custom fixtures
+const authTest = base.extend(createAuthFixtures());
+const profileTest = base.extend<ProfileFixtures>({
+  testProfile: async ({}, use) => {
+    // Dynamic test data with faker
+    const profile = {
+      name: faker.person.fullName(),
+      email: faker.internet.email(),
+      bio: faker.person.bio()
+    };
+
+    await use(profile);
+  }
+});
+
+export const test = mergeTests(authTest, profileTest);
+export { expect } from '@playwright/test';
+```
+
+**Usage:**
+```typescript
+import { test, expect } from '../support/fixtures/profile';
+
+test('should update profile', async ({ page, authToken, testProfile }) => {
+  // authToken from auth-session (automatic, persisted)
+  // testProfile from custom fixture (dynamic data)
+
+  await page.goto('/profile');
+  // Test with dynamic, unique data
+});
+```
+
+**Key Benefits:**
+- `authToken` fixture (persisted token, no manual login)
+- Dynamic test data with faker (no conflicts)
+- Fixture composition with mergeTests
+- Reusable across test files
+
+### 6. Review Additional Artifacts
+
+TEA also generates:
+
+#### Updated README (`tests/README.md`):
+
+```markdown
+# Test Suite
+
+## Running Tests
+
+### All Tests
+npm test
+
+### Specific Levels
+npm run test:api      # API tests only
+npm run test:e2e      # E2E tests only
+npm run test:smoke    # Smoke tests (@smoke tag)
+
+### Single File
+npx playwright test tests/api/profile.spec.ts
+
+## Test Structure
+
+tests/
+├── api/              # API tests (fast, reliable)
+├── e2e/              # E2E tests (full workflows)
+├── fixtures/         # Shared test utilities
+└── README.md
+
+## Writing Tests
+
+Follow the patterns in existing tests:
+- Use fixtures for authentication
+- Network-first patterns (no hard waits)
+- Explicit assertions
+- Self-cleaning tests
+```
+
+#### Definition of Done Summary:
+
+```markdown
+## Test Quality Checklist
+
+✅ All tests pass on first run
+✅ No hard waits (waitForTimeout)
+✅ No conditionals for flow control
+✅ Assertions are explicit
+✅ Tests clean up after themselves
+✅ Tests can run in parallel
+✅ Execution time < 1.5 minutes per test
+✅ Test files < 300 lines
+```
+
+### 7. Run the Tests
+
+All tests should pass immediately since the feature exists:
+
+**For Playwright:**
+```bash
+npx playwright test
+```
+
+**For Cypress:**
+```bash
+npx cypress run
+```
+
+Expected output:
+```
+Running 15 tests using 4 workers
+
+  ✓ tests/api/profile.spec.ts (4 tests) - 2.1s
+  ✓ tests/e2e/profile-workflow.spec.ts (2 tests) - 5.3s
+
+  15 passed (7.4s)
+```
+
+**All green!** Tests pass because feature already exists.
+
+### 8. Review Test Coverage
+
+Check which scenarios are covered:
+
+```bash
+# View test report
+npx playwright show-report
+
+# Check coverage (if configured)
+npm run test:coverage
+```
+
+Compare against:
+- Acceptance criteria from story
+- Test priorities from test design
+- Edge cases and error scenarios
+
+## What You Get
+
+### Comprehensive Test Suite
+- **API tests** - Fast, reliable backend testing
+- **E2E tests** - Critical user workflows
+- **Component tests** - UI component testing (if requested)
+- **Fixtures** - Shared utilities and setup
+
+### Component Testing by Framework
+
+TEA supports component testing using framework-appropriate tools:
+
+| Your Framework | Component Testing Tool         | Tests Location                            |
+| -------------- | ------------------------------ | ----------------------------------------- |
+| **Cypress**    | Cypress Component Testing      | `tests/component/`                        |
+| **Playwright** | Vitest + React Testing Library | `tests/component/` or `src/**/*.test.tsx` |
+
+**Note:** Component tests use separate tooling from E2E tests:
+- Cypress users: TEA generates Cypress Component Tests
+- Playwright users: TEA generates Vitest + React Testing Library tests
+
+### Quality Features
+- **Network-first patterns** - Wait for actual responses, not timeouts
+- **Deterministic tests** - No flakiness, no conditionals
+- **Self-cleaning** - Tests don't leave test data behind
+- **Parallel-safe** - Can run all tests concurrently
+
+### Documentation
+- **Updated README** - How to run tests
+- **Test structure explanation** - Where tests live
+- **Definition of Done** - Quality standards
+
+## Tips
+
+### Start with Test Design
+
+Run `*test-design` before `*automate` for better results:
+
+```
+*test-design   # Risk assessment, priorities
+*automate      # Generate tests based on priorities
+```
+
+TEA will focus on P0/P1 scenarios and skip low-value tests.
+
+### Prioritize Test Levels
+
+Not everything needs E2E tests:
+
+**Good strategy:**
+```
+- P0 scenarios: API + E2E tests
+- P1 scenarios: API tests only
+- P2 scenarios: API tests (happy path)
+- P3 scenarios: Skip or add later
+```
+
+**Why?**
+- API tests are 10x faster than E2E
+- API tests are more reliable (no browser flakiness)
+- E2E tests reserved for critical user journeys
+
+### Avoid Duplicate Coverage
+
+Tell TEA about existing tests:
+
+```
+We already have tests in:
+- tests/e2e/profile-view.spec.ts (viewing profile)
+- tests/api/auth.spec.ts (authentication)
+
+Don't duplicate that coverage
+```
+
+TEA will analyze existing tests and only generate new scenarios.
+
+### MCP Enhancements (Optional)
+
+If you have MCP servers configured (`tea_use_mcp_enhancements: true`), TEA can use them during `*automate` for:
+
+- **Healing mode:** Fix broken selectors, update assertions, enhance with trace analysis
+- **Recording mode:** Verify selectors with live browser, capture network requests
+
+No prompts - TEA uses MCPs automatically when available. See [Enable MCP Enhancements](/docs/how-to/customization/enable-tea-mcp-enhancements.md) for setup.
+
+### Generate Tests Incrementally
+
+Don't generate all tests at once:
+
+**Iteration 1:**
+```
+Generate P0 tests only (critical path)
+Run: *automate
+```
+
+**Iteration 2:**
+```
+Generate P1 tests (high value scenarios)
+Run: *automate
+Tell TEA to avoid P0 coverage
+```
+
+**Iteration 3:**
+```
+Generate P2 tests (if time permits)
+Run: *automate
+```
+
+This iterative approach:
+- Provides fast feedback
+- Allows validation before proceeding
+- Keeps test generation focused
+
+## Common Issues
+
+### Tests Pass But Coverage Is Incomplete
+
+**Problem:** Tests pass but don't cover all scenarios.
+
+**Cause:** TEA wasn't given complete context.
+
+**Solution:** Provide more details:
+```
+Generate tests for:
+- All acceptance criteria in story-profile.md
+- Error scenarios (validation, authorization)
+- Edge cases (empty fields, long inputs)
+```
+
+### Too Many Tests Generated
+
+**Problem:** TEA generated 50 tests for a simple feature.
+
+**Cause:** Didn't specify priorities or scope.
+
+**Solution:** Be specific:
+```
+Generate ONLY:
+- P0 and P1 scenarios
+- API tests for all scenarios
+- E2E tests only for critical workflows
+- Skip P2/P3 for now
+```
+
+### Tests Duplicate Existing Coverage
+
+**Problem:** New tests cover the same scenarios as existing tests.
+
+**Cause:** Didn't tell TEA about existing tests.
+
+**Solution:** Specify existing coverage:
+```
+We already have these tests:
+- tests/api/profile.spec.ts (GET /api/profile)
+- tests/e2e/profile-view.spec.ts (viewing profile)
+
+Generate tests for scenarios NOT covered by those files
+```
+
+### MCP Enhancements for Better Selectors
+
+If you have MCP servers configured, TEA verifies selectors against live browser. Otherwise, TEA generates accessible selectors (`getByRole`, `getByLabel`) by default.
+
+Setup: Answer "Yes" to MCPs in BMad installer + configure MCP servers in your IDE. See [Enable MCP Enhancements](/docs/how-to/customization/enable-tea-mcp-enhancements.md).
+
+## Related Guides
+
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md) - Plan before generating
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md) - Failing tests before implementation
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md) - Audit generated quality
+
+## Understanding the Concepts
+
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - **Why TEA generates quality tests** (foundational)
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Why prioritize P0 over P3
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - What makes tests good
+- [Fixture Architecture](/docs/explanation/tea/fixture-architecture.md) - Reusable test patterns
+
+## Reference
+
+- [Command: *automate](/docs/reference/tea/commands.md#automate) - Full command reference
+- [TEA Configuration](/docs/reference/tea/configuration.md) - MCP and Playwright Utils options
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/workflows/run-brainstorming-session.md

@@ -3,11 +3,8 @@ title: "How to Run a Brainstorming Session"
 description: How to run a brainstorming session using the BMad Method
 ---
 
-
 Use the `brainstorm-project` workflow to explore solution approaches through parallel ideation tracks.
 
----
-
 ## When to Use This
 
 - Very vague or seed kernel of an idea that needs exploration
@@ -15,14 +12,10 @@ Use the `brainstorm-project` workflow to explore solution approaches through par
 - See your idea from different angles and viewpoints
 - No idea what you want to build, but want to find some inspiration
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - Analyst agent available
-
----
+:::
 
 ## Steps
 
@@ -48,17 +41,15 @@ Tell the agent about your project idea, even if it's vague:
 
 The workflow generates solution approaches through parallel ideation tracks:
 
-- **Architecture track** - Technical approaches and patterns
-- **UX track** - User experience possibilities
-- **Integration track** - How it connects with other systems
-- **Value track** - Business value and differentiation
+- **Architecture track** — Technical approaches and patterns
+- **UX track** — User experience possibilities
+- **Integration track** — How it connects with other systems
+- **Value track** — Business value and differentiation
 
 ### 5. Evaluate Options
 
 Review the generated options with rationale for each approach.
 
----
-
 ## What You Get
 
 - Multiple solution approaches with trade-offs
@@ -66,29 +57,17 @@ Review the generated options with rationale for each approach.
 - UX and integration considerations
 - Clear rationale for each direction
 
----
+## Tips
+
+- **Don't worry about having a fully formed idea** — Vague is fine
+- **Let the agent guide exploration** — Follow the prompts
+- **Consider multiple tracks** — Don't settle on the first option
+- **Use outputs as input for product-brief** — Build on brainstorming results
 
 ## Next Steps
 
 After brainstorming:
 
-1. **Research** - Validate ideas with market/technical research
-2. **Product Brief** - Capture strategic vision
-3. **PRD** - Move to formal planning
-
----
-
-## Tips
-
-- Don't worry about having a fully formed idea
-- Let the agent guide the exploration
-- Consider multiple tracks before deciding
-- Use outputs as input for product-brief workflow
-
----
-
-## Related
-
-- [Conduct Research](/docs/how-to/workflows/conduct-research.md) - Validate your ideas
-- [Create Product Brief](/docs/how-to/workflows/create-product-brief.md) - Capture strategic vision
-- [Create PRD](/docs/how-to/workflows/create-prd.md) - Move to formal planning
+1. **Research** — Validate ideas with market/technical research
+2. **Product Brief** — Capture strategic vision
+3. **PRD** — Move to formal planning

docs/how-to/workflows/run-code-review.md

@@ -3,27 +3,20 @@ title: "How to Run Code Review"
 description: How to run code review for quality assurance
 ---
 
-
 Use the `code-review` workflow to perform a thorough quality review of implemented code.
 
----
-
 ## When to Use This
 
 - After dev-story completes implementation
 - Before marking a story as DONE
-- Every story goes through code review - no exceptions
-
----
-
-## Prerequisites
+- Every story goes through code review — no exceptions
 
+:::note[Prerequisites]
 - BMad Method installed
 - DEV agent available
 - Story implementation complete
 - Tests written and passing
-
----
+:::
 
 ## Steps
 
@@ -55,56 +48,21 @@ If issues are found:
 2. Re-run tests
 3. Run code-review again
 
----
-
 ## What Gets Reviewed
 
-The code review checks:
-
-### Code Quality
-- Clean, readable code
-- Appropriate abstractions
-- No code smells
-- Proper error handling
-
-### Architecture Alignment
-- Follows ADRs and architecture decisions
-- Consistent with existing patterns
-- Proper separation of concerns
-
-### Testing
-- Adequate test coverage
-- Tests are meaningful (not just for coverage)
-- Edge cases handled
-- Tests follow project patterns
-
-### Security
-- No hardcoded secrets
-- Input validation
-- Authentication/authorization proper
-- No common vulnerabilities
-
-### Performance
-- No obvious performance issues
-- Appropriate data structures
-- Efficient queries
-
----
+| Category | Checks |
+|----------|--------|
+| **Code Quality** | Clean code, appropriate abstractions, no code smells, proper error handling |
+| **Architecture Alignment** | Follows ADRs, consistent with patterns, proper separation of concerns |
+| **Testing** | Adequate coverage, meaningful tests, edge cases, follows project patterns |
+| **Security** | No hardcoded secrets, input validation, proper auth, no common vulnerabilities |
+| **Performance** | No obvious issues, appropriate data structures, efficient queries |
 
 ## Review Outcomes
 
-### ✅ Approved
+**Approved** — Code meets quality standards, tests pass. Mark story as DONE in sprint-status.yaml.
 
-- Code meets quality standards
-- Tests pass
-- **Action:** Mark story as DONE in sprint-status.yaml
-
-### 🔧 Changes Requested
-
-- Issues identified that need fixing
-- **Action:** Fix issues in dev-story, then re-run code-review
-
----
+**Changes Requested** — Issues identified that need fixing. Fix issues in dev-story, then re-run code-review.
 
 ## Quality Gates
 
@@ -115,27 +73,17 @@ Every story goes through code-review before being marked done. This ensures:
 - Test coverage
 - Security review
 
----
-
 ## Tips
 
-- Don't skip code review for "simple" changes
-- Address all findings, not just critical ones
-- Use findings as learning opportunities
-- Re-run review after fixes
+- **Don't skip for "simple" changes** — Simple changes can have subtle bugs
+- **Address all findings** — Not just critical ones
+- **Use findings as learning opportunities** — Improve over time
+- **Re-run review after fixes** — Verify issues are resolved
 
----
+## Next Steps
 
-## After Code Review
+After code review:
 
-1. **If approved:** Update sprint-status.yaml to mark story DONE
-2. **If changes requested:** Fix issues and re-run review
-3. **Move to next story:** Run create-story for the next item
-
----
-
-## Related
-
-- [Implement Story](/docs/how-to/workflows/implement-story.md) - Before code review
-- [Create Story](/docs/how-to/workflows/create-story.md) - Move to next story
-- [Run Sprint Planning](/docs/how-to/workflows/run-sprint-planning.md) - Sprint organization
+1. **If approved** — Update sprint-status.yaml to mark story DONE
+2. **If changes requested** — Fix issues and re-run review
+3. **Move to next story** — Run create-story for the next item

docs/how-to/workflows/run-implementation-readiness.md

@@ -3,11 +3,8 @@ title: "How to Run Implementation Readiness"
 description: How to validate planning and solutioning before implementation
 ---
 
-
 Use the `implementation-readiness` workflow to validate that planning and solutioning are complete and aligned before Phase 4 implementation.
 
----
-
 ## When to Use This
 
 - **Always** before Phase 4 for BMad Method and Enterprise projects
@@ -15,22 +12,16 @@ Use the `implementation-readiness` workflow to validate that planning and soluti
 - Before sprint-planning workflow
 - When stakeholders request readiness check
 
----
-
 ## When to Skip This
 
 - Quick Flow (no solutioning phase)
 - BMad Method Simple (no gate check required)
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - Architect agent available
 - PRD, Architecture, and Epics completed
-
----
+:::
 
 ## Steps
 
@@ -56,66 +47,42 @@ The workflow systematically checks:
 
 The agent produces a gate decision with rationale.
 
----
-
 ## Gate Decision Outcomes
 
-### ✅ PASS
-
-- All critical criteria met
-- Minor gaps acceptable with documented plan
-- **Action:** Proceed to Phase 4
-
-### ⚠️ CONCERNS
-
-- Some criteria not met but not blockers
-- Gaps identified with clear resolution path
-- **Action:** Proceed with caution, address gaps in parallel
-
-### ❌ FAIL
-
-- Critical gaps or contradictions
-- Architecture missing key decisions
-- Epics conflict with PRD/architecture
-- **Action:** BLOCK Phase 4, resolve issues first
-
----
+| Decision | Meaning | Action |
+|----------|---------|--------|
+| **PASS** | All critical criteria met, minor gaps acceptable | Proceed to Phase 4 |
+| **CONCERNS** | Some criteria not met but not blockers | Proceed with caution, address gaps in parallel |
+| **FAIL** | Critical gaps or contradictions | BLOCK Phase 4, resolve issues first |
 
 ## What Gets Checked
 
-### PRD/GDD Completeness
+**PRD/GDD Completeness:**
 - Problem statement clear and evidence-based
 - Success metrics defined
 - User personas identified
-- Functional requirements (FRs) complete
-- Non-functional requirements (NFRs) specified
+- FRs and NFRs complete
 - Risks and assumptions documented
 
-### Architecture Completeness
-- System architecture defined
-- Data architecture specified
-- API architecture decided
+**Architecture Completeness:**
+- System, data, API architecture defined
 - Key ADRs documented
 - Security architecture addressed
 - FR/NFR-specific guidance provided
 - Standards and conventions defined
 
-### Epic/Story Completeness
+**Epic/Story Completeness:**
 - All PRD features mapped to stories
 - Stories have acceptance criteria
 - Stories prioritized (P0/P1/P2/P3)
 - Dependencies identified
-- Story sequencing logical
 
-### Alignment Checks
+**Alignment Checks:**
 - Architecture addresses all PRD FRs/NFRs
 - Epics align with architecture decisions
 - No contradictions between epics
-- NFRs have technical approach
 - Integration points clear
 
----
-
 ## What You Get
 
 An `implementation-readiness.md` document containing:
@@ -128,11 +95,9 @@ An `implementation-readiness.md` document containing:
 6. **Gate Decision** with rationale
 7. **Next Steps**
 
----
-
 ## Example
 
-E-commerce platform → CONCERNS ⚠️
+E-commerce platform → CONCERNS
 
 **Gaps identified:**
 - Missing security architecture section
@@ -144,19 +109,17 @@ E-commerce platform → CONCERNS ⚠️
 
 **Action:** Proceed with caution, address before payment epic.
 
----
-
 ## Tips
 
-- Run this before every Phase 4 start
-- Take FAIL decisions seriously - fix issues first
-- Use CONCERNS as a checklist for parallel work
-- Document why you proceed despite concerns
+- **Run before every Phase 4 start** — It's a valuable checkpoint
+- **Take FAIL decisions seriously** — Fix issues first
+- **Use CONCERNS as a checklist** — Track parallel work
+- **Document why you proceed despite concerns** — Transparency matters
 
----
+## Next Steps
 
-## Related
+After implementation readiness:
 
-- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Architecture workflow
-- [Create Epics and Stories](/docs/how-to/workflows/create-epics-and-stories.md) - Work breakdown
-- [Run Sprint Planning](/docs/how-to/workflows/run-sprint-planning.md) - Start implementation
+1. **If PASS** — Run sprint-planning to start Phase 4
+2. **If CONCERNS** — Proceed with documented gaps to address
+3. **If FAIL** — Return to relevant workflow to fix issues

docs/how-to/workflows/run-nfr-assess.md

@@ -0,0 +1,679 @@
+---
+title: "How to Run NFR Assessment with TEA"
+description: Validate non-functional requirements for security, performance, reliability, and maintainability using TEA
+---
+
+# How to Run NFR Assessment with TEA
+
+Use TEA's `*nfr-assess` workflow to validate non-functional requirements (NFRs) with evidence-based assessment across security, performance, reliability, and maintainability.
+
+## When to Use This
+
+- Enterprise projects with compliance requirements
+- Projects with strict NFR thresholds
+- Before production release
+- When NFRs are critical to project success
+- Security or performance is mission-critical
+
+**Best for:**
+- Enterprise track projects
+- Compliance-heavy industries (finance, healthcare, government)
+- High-traffic applications
+- Security-critical systems
+
+## Prerequisites
+
+- BMad Method installed
+- TEA agent available
+- NFRs defined in PRD or requirements doc
+- Evidence preferred but not required (test results, security scans, performance metrics)
+
+**Note:** You can run NFR assessment without complete evidence. TEA will mark categories as CONCERNS where evidence is missing and document what's needed.
+
+## Steps
+
+### 1. Run the NFR Assessment Workflow
+
+Start a fresh chat and run:
+
+```
+*nfr-assess
+```
+
+This loads TEA and starts the NFR assessment workflow.
+
+### 2. Specify NFR Categories
+
+TEA will ask which NFR categories to assess.
+
+**Available Categories:**
+
+| Category | Focus Areas |
+|----------|-------------|
+| **Security** | Authentication, authorization, encryption, vulnerabilities, security headers, input validation |
+| **Performance** | Response time, throughput, resource usage, database queries, frontend load time |
+| **Reliability** | Error handling, recovery mechanisms, availability, failover, data backup |
+| **Maintainability** | Code quality, test coverage, technical debt, documentation, dependency health |
+
+**Example Response:**
+```
+Assess:
+- Security (critical for user data)
+- Performance (API must be fast)
+- Reliability (99.9% uptime requirement)
+
+Skip maintainability for now
+```
+
+### 3. Provide NFR Thresholds
+
+TEA will ask for specific thresholds for each category.
+
+**Critical Principle: Never guess thresholds.**
+
+If you don't know the exact requirement, tell TEA to mark as CONCERNS and request clarification from stakeholders.
+
+#### Security Thresholds
+
+**Example:**
+```
+Requirements:
+- All endpoints require authentication: YES
+- Data encrypted at rest: YES (PostgreSQL TDE)
+- Zero critical vulnerabilities: YES (npm audit)
+- Input validation on all endpoints: YES (Zod schemas)
+- Security headers configured: YES (helmet.js)
+```
+
+#### Performance Thresholds
+
+**Example:**
+```
+Requirements:
+- API response time P99: < 200ms
+- API response time P95: < 150ms
+- Throughput: > 1000 requests/second
+- Frontend initial load: < 2 seconds
+- Database query time P99: < 50ms
+```
+
+#### Reliability Thresholds
+
+**Example:**
+```
+Requirements:
+- Error handling: All endpoints return structured errors
+- Availability: 99.9% uptime
+- Recovery time: < 5 minutes (RTO)
+- Data backup: Daily automated backups
+- Failover: Automatic with < 30s downtime
+```
+
+#### Maintainability Thresholds
+
+**Example:**
+```
+Requirements:
+- Test coverage: > 80%
+- Code quality: SonarQube grade A
+- Documentation: All APIs documented
+- Dependency age: < 6 months outdated
+- Technical debt: < 10% of codebase
+```
+
+### 4. Provide Evidence
+
+TEA will ask where to find evidence for each requirement.
+
+**Evidence Sources:**
+
+| Category | Evidence Type | Location |
+|----------|---------------|----------|
+| Security | Security scan reports | `/reports/security-scan.pdf` |
+| Security | Vulnerability scan | `npm audit`, `snyk test` results |
+| Security | Auth test results | Test reports showing auth coverage |
+| Performance | Load test results | `/reports/k6-load-test.json` |
+| Performance | APM data | Datadog, New Relic dashboards |
+| Performance | Lighthouse scores | `/reports/lighthouse.json` |
+| Reliability | Error rate metrics | Production monitoring dashboards |
+| Reliability | Uptime data | StatusPage, PagerDuty logs |
+| Maintainability | Coverage reports | `/reports/coverage/index.html` |
+| Maintainability | Code quality | SonarQube dashboard |
+
+**Example Response:**
+```
+Evidence:
+- Security: npm audit results (clean), auth tests 15/15 passing
+- Performance: k6 load test at /reports/k6-results.json
+- Reliability: Error rate 0.01% in staging (logs in Datadog)
+
+Don't have:
+- Uptime data (new system, no baseline)
+- Mark as CONCERNS and request monitoring setup
+```
+
+### 5. Review NFR Assessment Report
+
+TEA generates a comprehensive assessment report.
+
+#### Assessment Report (`nfr-assessment.md`):
+
+```markdown
+# Non-Functional Requirements Assessment
+
+**Date:** 2026-01-13
+**Epic:** User Profile Management
+**Release:** v1.2.0
+**Overall Decision:** CONCERNS ⚠️
+
+## Executive Summary
+
+| Category | Status | Critical Issues |
+|----------|--------|-----------------|
+| Security | PASS ✅ | 0 |
+| Performance | CONCERNS ⚠️ | 2 |
+| Reliability | PASS ✅ | 0 |
+| Maintainability | PASS ✅ | 0 |
+
+**Decision Rationale:**
+Performance metrics below target (P99 latency, throughput). Mitigation plan in place. Security and reliability meet all requirements.
+
+---
+
+## Security Assessment
+
+**Status:** PASS ✅
+
+### Requirements Met
+
+| Requirement | Target | Actual | Status |
+|-------------|--------|--------|--------|
+| Authentication required | All endpoints | 100% enforced | ✅ |
+| Data encryption at rest | PostgreSQL TDE | Enabled | ✅ |
+| Critical vulnerabilities | 0 | 0 | ✅ |
+| Input validation | All endpoints | Zod schemas on 100% | ✅ |
+| Security headers | Configured | helmet.js enabled | ✅ |
+
+### Evidence
+
+**Security Scan:**
+```bash
+$ npm audit
+found 0 vulnerabilities
+```
+
+**Authentication Tests:**
+- 15/15 auth tests passing
+- Tested unauthorized access (401 responses)
+- Token validation working
+
+**Penetration Testing:**
+- Report: `/reports/pentest-2026-01.pdf`
+- Findings: 0 critical, 2 low (addressed)
+
+**Conclusion:** All security requirements met. No blockers.
+
+---
+
+## Performance Assessment
+
+**Status:** CONCERNS ⚠️
+
+### Requirements Status
+
+| Metric | Target | Actual | Status |
+|--------|--------|--------|--------|
+| API response P99 | < 200ms | 350ms | ❌ Exceeds |
+| API response P95 | < 150ms | 180ms | ⚠️ Exceeds |
+| Throughput | > 1000 rps | 850 rps | ⚠️ Below |
+| Frontend load | < 2s | 1.8s | ✅ Met |
+| DB query P99 | < 50ms | 85ms | ❌ Exceeds |
+
+### Issues Identified
+
+#### Issue 1: P99 Latency Exceeds Target
+
+**Measured:** 350ms P99 (target: <200ms)
+**Root Cause:** Database queries not optimized
+- Missing indexes on profile queries
+- N+1 query problem in profile endpoint
+
+**Impact:** User experience degraded for 1% of requests
+
+**Mitigation Plan:**
+- Add composite index on `(user_id, profile_id)` - backend team, 2 days
+- Refactor profile endpoint to use joins instead of multiple queries - backend team, 3 days
+- Re-run load tests after optimization - QA team, 1 day
+
+**Owner:** Backend team lead
+**Deadline:** Before release (January 20, 2026)
+
+#### Issue 2: Throughput Below Target
+
+**Measured:** 850 rps (target: >1000 rps)
+**Root Cause:** Connection pool size too small
+- PostgreSQL max_connections = 100 (too low)
+- No connection pooling in application
+
+**Impact:** System cannot handle expected traffic
+
+**Mitigation Plan:**
+- Increase PostgreSQL max_connections to 500 - DevOps, 1 day
+- Implement connection pooling with pg-pool - backend team, 2 days
+- Re-run load tests - QA team, 1 day
+
+**Owner:** DevOps + Backend team
+**Deadline:** Before release (January 20, 2026)
+
+### Evidence
+
+**Load Testing:**
+```
+Tool: k6
+Duration: 10 minutes
+Virtual Users: 500 concurrent
+Report: /reports/k6-load-test.json
+```
+
+**Results:**
+```
+scenarios: (100.00%) 1 scenario, 500 max VUs, 10m30s max duration
+     ✓ http_req_duration..............: avg=250ms min=45ms med=180ms max=2.1s p(90)=280ms p(95)=350ms
+     http_reqs......................: 85000 (850/s)
+     http_req_failed................: 0.1%
+```
+
+**APM Data:**
+- Tool: Datadog
+- Dashboard: <https://app.datadoghq.com/dashboard/abc123>
+
+**Conclusion:** Performance issues identified with mitigation plan. Re-assess after optimization.
+
+---
+
+## Reliability Assessment
+
+**Status:** PASS ✅
+
+### Requirements Met
+
+| Requirement | Target | Actual | Status |
+|-------------|--------|--------|--------|
+| Error handling | Structured errors | 100% endpoints | ✅ |
+| Availability | 99.9% uptime | 99.95% (staging) | ✅ |
+| Recovery time | < 5 min (RTO) | 3 min (tested) | ✅ |
+| Data backup | Daily | Automated daily | ✅ |
+| Failover | < 30s downtime | 15s (tested) | ✅ |
+
+### Evidence
+
+**Error Handling Tests:**
+- All endpoints return structured JSON errors
+- Error codes standardized (400, 401, 403, 404, 500)
+- Error messages user-friendly (no stack traces)
+
+**Chaos Engineering:**
+- Tested database failover: 15s downtime ✅
+- Tested service crash recovery: 3 min ✅
+- Tested network partition: Graceful degradation ✅
+
+**Monitoring:**
+- Staging uptime (30 days): 99.95%
+- Error rate: 0.01% (target: <0.1%)
+- P50 availability: 100%
+
+**Conclusion:** All reliability requirements exceeded. No issues.
+
+---
+
+## Maintainability Assessment
+
+**Status:** PASS ✅
+
+### Requirements Met
+
+| Requirement | Target | Actual | Status |
+|-------------|--------|--------|--------|
+| Test coverage | > 80% | 85% | ✅ |
+| Code quality | Grade A | Grade A | ✅ |
+| Documentation | All APIs | 100% documented | ✅ |
+| Outdated dependencies | < 6 months | 3 months avg | ✅ |
+| Technical debt | < 10% | 7% | ✅ |
+
+### Evidence
+
+**Test Coverage:**
+```
+Statements   : 85.2% ( 1205/1414 )
+Branches     : 82.1% ( 412/502 )
+Functions    : 88.5% ( 201/227 )
+Lines        : 85.2% ( 1205/1414 )
+```
+
+**Code Quality:**
+- SonarQube: Grade A
+- Maintainability rating: A
+- Technical debt ratio: 7%
+- Code smells: 12 (all minor)
+
+**Documentation:**
+- API docs: 100% coverage (OpenAPI spec)
+- README: Complete and up-to-date
+- Architecture docs: ADRs for all major decisions
+
+**Conclusion:** All maintainability requirements met. Codebase is healthy.
+
+---
+
+## Overall Gate Decision
+
+### Decision: CONCERNS ⚠️
+
+**Rationale:**
+- **Blockers:** None
+- **Concerns:** Performance metrics below target (P99 latency, throughput)
+- **Mitigation:** Plan in place with clear owners and deadlines (5 days total)
+- **Passing:** Security, reliability, maintainability all green
+
+### Actions Required Before Release
+
+1. **Optimize database queries** (backend team, 3 days)
+   - Add indexes
+   - Fix N+1 queries
+   - Implement connection pooling
+
+2. **Re-run performance tests** (QA team, 1 day)
+   - Validate P99 < 200ms
+   - Validate throughput > 1000 rps
+
+3. **Update this assessment** (TEA, 1 hour)
+   - Re-run `*nfr-assess` with new results
+   - Confirm PASS status
+
+### Waiver Option (If Business Approves)
+
+If business decides to deploy with current performance:
+
+**Waiver Justification:**
+```markdown
+## Performance Waiver
+
+**Waived By:** VP Engineering, Product Manager
+**Date:** 2026-01-15
+**Reason:** Business priority to launch by Q1
+**Conditions:**
+- Set monitoring alerts for P99 > 300ms
+- Plan optimization for v1.3 (February release)
+- Document known performance limitations in release notes
+
+**Accepted Risk:**
+- 1% of users experience slower response (350ms vs 200ms)
+- System can handle current traffic (850 rps sufficient for launch)
+- Optimization planned for next release
+```
+
+### Approvals
+
+- [ ] Product Manager - Review business impact
+- [ ] Tech Lead - Review mitigation plan
+- [ ] QA Lead - Validate test evidence
+- [ ] DevOps - Confirm infrastructure ready
+
+---
+
+## Monitoring Plan Post-Release
+
+**Performance Alerts:**
+- P99 latency > 400ms (critical)
+- Throughput < 700 rps (warning)
+- Error rate > 1% (critical)
+
+**Review Cadence:**
+- Daily: Check performance dashboards
+- Weekly: Review alert trends
+- Monthly: Re-assess NFRs
+```
+
+## What You Get
+
+### NFR Assessment Report
+- Category-by-category analysis (Security, Performance, Reliability, Maintainability)
+- Requirements status (target vs actual)
+- Evidence for each requirement
+- Issues identified with root cause analysis
+
+### Gate Decision
+- **PASS** ✅ - All NFRs met, ready to release
+- **CONCERNS** ⚠️ - Some NFRs not met, mitigation plan exists
+- **FAIL** ❌ - Critical NFRs not met, blocks release
+- **WAIVED** ⏭️ - Business-approved waiver with documented risk
+
+### Mitigation Plans
+- Specific actions to address concerns
+- Owners and deadlines
+- Re-assessment criteria
+
+### Monitoring Plan
+- Post-release monitoring strategy
+- Alert thresholds
+- Review cadence
+
+## Tips
+
+### Run NFR Assessment Early
+
+**Phase 2 (Enterprise):**
+Run `*nfr-assess` during planning to:
+- Identify NFR requirements early
+- Plan for performance testing
+- Budget for security audits
+- Set up monitoring infrastructure
+
+**Phase 4 or Gate:**
+Re-run before release to validate all requirements met.
+
+### Never Guess Thresholds
+
+If you don't know the NFR target:
+
+**Don't:**
+```
+API response time should probably be under 500ms
+```
+
+**Do:**
+```
+Mark as CONCERNS - Request threshold from stakeholders
+"What is the acceptable API response time?"
+```
+
+### Collect Evidence Beforehand
+
+Before running `*nfr-assess`, gather:
+
+**Security:**
+```bash
+npm audit                    # Vulnerability scan
+snyk test                    # Alternative security scan
+npm run test:security        # Security test suite
+```
+
+**Performance:**
+```bash
+npm run test:load            # k6 or artillery load tests
+npm run test:lighthouse      # Frontend performance
+npm run test:db-performance  # Database query analysis
+```
+
+**Reliability:**
+- Production error rate (last 30 days)
+- Uptime data (StatusPage, PagerDuty)
+- Incident response times
+
+**Maintainability:**
+```bash
+npm run test:coverage        # Test coverage report
+npm run lint                 # Code quality check
+npm outdated                 # Dependency freshness
+```
+
+### Use Real Data, Not Assumptions
+
+**Don't:**
+```
+System is probably fast enough
+Security seems fine
+```
+
+**Do:**
+```
+Load test results show P99 = 350ms
+npm audit shows 0 vulnerabilities
+Test coverage report shows 85%
+```
+
+Evidence-based decisions prevent surprises in production.
+
+### Document Waivers Thoroughly
+
+If business approves waiver:
+
+**Required:**
+- Who approved (name, role, date)
+- Why (business justification)
+- Conditions (monitoring, future plans)
+- Accepted risk (quantified impact)
+
+**Example:**
+```markdown
+Waived by: CTO, VP Product (2026-01-15)
+Reason: Q1 launch critical for investor demo
+Conditions: Optimize in v1.3, monitor closely
+Risk: 1% of users experience 350ms latency (acceptable for launch)
+```
+
+### Re-Assess After Fixes
+
+After implementing mitigations:
+
+```
+1. Fix performance issues
+2. Run load tests again
+3. Run *nfr-assess with new evidence
+4. Verify PASS status
+```
+
+Don't deploy with CONCERNS without mitigation or waiver.
+
+### Integrate with Release Checklist
+
+```markdown
+## Release Checklist
+
+### Pre-Release
+- [ ] All tests passing
+- [ ] Test coverage > 80%
+- [ ] Run *nfr-assess
+- [ ] NFR status: PASS or WAIVED
+
+### Performance
+- [ ] Load tests completed
+- [ ] P99 latency meets threshold
+- [ ] Throughput meets threshold
+
+### Security
+- [ ] Security scan clean
+- [ ] Auth tests passing
+- [ ] Penetration test complete
+
+### Post-Release
+- [ ] Monitoring alerts configured
+- [ ] Dashboards updated
+- [ ] Incident response plan ready
+```
+
+## Common Issues
+
+### No Evidence Available
+
+**Problem:** Don't have performance data, security scans, etc.
+
+**Solution:**
+```
+Mark as CONCERNS for categories without evidence
+Document what evidence is needed
+Set up tests/scans before re-assessment
+```
+
+**Don't block on missing evidence** - document what's needed and proceed.
+
+### Thresholds Too Strict
+
+**Problem:** Can't meet unrealistic thresholds.
+
+**Symptoms:**
+- P99 < 50ms (impossible for complex queries)
+- 100% test coverage (impractical)
+- Zero technical debt (unrealistic)
+
+**Solution:**
+```
+Negotiate thresholds with stakeholders:
+- "P99 < 50ms is unrealistic for our DB queries"
+- "Propose P99 < 200ms based on industry standards"
+- "Show evidence from load tests"
+```
+
+Use data to negotiate realistic requirements.
+
+### Assessment Takes Too Long
+
+**Problem:** Gathering evidence for all categories is time-consuming.
+
+**Solution:** Focus on critical categories first:
+
+**For most projects:**
+```
+Priority 1: Security (always critical)
+Priority 2: Performance (if high-traffic)
+Priority 3: Reliability (if uptime critical)
+Priority 4: Maintainability (nice to have)
+```
+
+Assess categories incrementally, not all at once.
+
+### CONCERNS vs FAIL - When to Block?
+
+**CONCERNS** ⚠️:
+- Issues exist but not critical
+- Mitigation plan in place
+- Business accepts risk (with waiver)
+- Can deploy with monitoring
+
+**FAIL** ❌:
+- Critical security vulnerability (CVE critical)
+- System unusable (error rate >10%)
+- Data loss risk (no backups)
+- Zero mitigation possible
+
+**Rule of thumb:** If you can mitigate or monitor, use CONCERNS. Reserve FAIL for absolute blockers.
+
+## Related Guides
+
+- [How to Run Trace](/docs/how-to/workflows/run-trace.md) - Gate decision complements NFR
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md) - Quality complements NFR
+- [Run TEA for Enterprise](/docs/how-to/brownfield/use-tea-for-enterprise.md) - Enterprise workflow
+
+## Understanding the Concepts
+
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Risk assessment principles
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - NFR in release gates
+
+## Reference
+
+- [Command: *nfr-assess](/docs/reference/tea/commands.md#nfr-assess) - Full command reference
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Enterprise config options
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/workflows/run-sprint-planning.md

@@ -3,27 +3,20 @@ title: "How to Run Sprint Planning"
 description: How to initialize sprint tracking for implementation
 ---
 
-
 Use the `sprint-planning` workflow to initialize the sprint tracking file and organize work for implementation.
 
----
-
 ## When to Use This
 
 - Once at the start of Phase 4 (Implementation)
 - After implementation-readiness gate passes
 - When starting a new sprint cycle
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - SM (Scrum Master) agent available
 - Epic files created from `create-epics-and-stories`
 - Implementation-readiness passed (for BMad Method/Enterprise)
-
----
+:::
 
 ## Steps
 
@@ -45,8 +38,6 @@ Point the agent to your epic files created during Phase 3.
 
 The agent organizes stories into the sprint tracking file.
 
----
-
 ## What You Get
 
 A `sprint-status.yaml` file containing:
@@ -56,12 +47,8 @@ A `sprint-status.yaml` file containing:
 - Dependencies between stories
 - Priority ordering
 
----
-
 ## Story Lifecycle States
 
-Stories move through these states in the sprint status file:
-
 | State | Description |
 |-------|-------------|
 | **TODO** | Story identified but not started |
@@ -69,43 +56,39 @@ Stories move through these states in the sprint status file:
 | **READY FOR REVIEW** | Implementation complete, awaiting code review |
 | **DONE** | Accepted and complete |
 
----
-
 ## Typical Sprint Flow
 
-### Sprint 0 (Planning Phase)
+**Sprint 0 (Planning Phase):**
 - Complete Phases 1-3
 - PRD/GDD + Architecture complete
 - Epics+Stories created via create-epics-and-stories
 
-### Sprint 1+ (Implementation Phase)
+**Sprint 1+ (Implementation Phase):**
 
-**Start of Phase 4:**
+Start of Phase 4:
 1. SM runs `sprint-planning` (once)
 
-**Per Story (repeat until epic complete):**
+Per Story (repeat until epic complete):
 1. SM runs `create-story`
 2. DEV runs `dev-story`
 3. DEV runs `code-review`
 4. Update sprint-status.yaml
 
-**After Epic Complete:**
+After Epic Complete:
 - SM runs `retrospective`
 - Move to next epic
 
----
-
 ## Tips
 
-- Run sprint-planning only once at Phase 4 start
-- Use `sprint-status` during Phase 4 to check current state
-- Keep the sprint-status.yaml file as single source of truth
-- Update story status after each stage
+- **Run sprint-planning only once** — At Phase 4 start
+- **Use sprint-status during Phase 4** — Check current state anytime
+- **Keep sprint-status.yaml as single source of truth** — All status updates go here
+- **Update story status after each stage** — Keep it current
 
----
+## Next Steps
 
-## Related
+After sprint planning:
 
-- [Create Story](/docs/how-to/workflows/create-story.md) - Prepare stories for implementation
-- [Implement Story](/docs/how-to/workflows/implement-story.md) - Dev workflow
-- [Run Code Review](/docs/how-to/workflows/run-code-review.md) - Quality assurance
+1. **Create Story** — Prepare the first story for implementation
+2. **Implement Story** — Run dev-story with the DEV agent
+3. **Code Review** — Quality assurance after implementation

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

@@ -1,13 +1,10 @@
 ---
-title: "How to Run Test Design"
+title: "How to Run Test Design with TEA"
 description: How to create comprehensive test plans using TEA's test-design workflow
 ---
 
-
 Use TEA's `*test-design` workflow to create comprehensive test plans with risk assessment and coverage strategies.
 
----
-
 ## When to Use This
 
 **System-level (Phase 3):**
@@ -20,16 +17,12 @@ Use TEA's `*test-design` workflow to create comprehensive test plans with risk a
 - Before implementing stories in the epic
 - To identify epic-specific testing needs
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - TEA agent available
 - For system-level: Architecture document complete
 - For epic-level: Epic defined with stories
-
----
+:::
 
 ## Steps
 
@@ -47,8 +40,8 @@ Start a fresh chat and load the TEA (Test Architect) agent.
 
 TEA will ask if you want:
 
-- **System-level** - For architecture testability review (Phase 3)
-- **Epic-level** - For epic-specific test planning (Phase 4)
+- **System-level** — For architecture testability review (Phase 3)
+- **Epic-level** — For epic-specific test planning (Phase 4)
 
 ### 4. Provide Context
 
@@ -64,20 +57,16 @@ For epic-level:
 
 TEA generates a comprehensive test design document.
 
----
-
 ## What You Get
 
-### System-Level Output (`test-design-system.md`)
-
+**System-Level Output (`test-design-system.md`):**
 - Testability review of architecture
 - ADR → test mapping
 - Architecturally Significant Requirements (ASRs)
 - Environment needs
 - Test infrastructure recommendations
 
-### Epic-Level Output (`test-design-epic-N.md`)
-
+**Epic-Level Output (`test-design-epic-N.md`):**
 - Risk assessment for the epic
 - Test priorities
 - Coverage plan
@@ -85,44 +74,25 @@ TEA generates a comprehensive test design document.
 - Integration risks
 - Mitigation strategies
 
----
-
 ## Test Design for Different Tracks
 
-### Greenfield - BMad Method
-
-| Stage | Test Design Focus |
-|-------|-------------------|
-| Phase 3 | System-level testability review |
-| Phase 4 | Per-epic risk assessment and test plan |
-
-### Brownfield - BMad Method/Enterprise
-
-| Stage | Test Design Focus |
-|-------|-------------------|
-| Phase 3 | System-level + existing test baseline |
-| Phase 4 | Regression hotspots, integration risks |
-
-### Enterprise
-
-| Stage | Test Design Focus |
-|-------|-------------------|
-| Phase 3 | Compliance-aware testability |
-| Phase 4 | Security/performance/compliance focus |
-
----
+| Track | Phase 3 Focus | Phase 4 Focus |
+|-------|---------------|---------------|
+| **Greenfield** | System-level testability review | Per-epic risk assessment and test plan |
+| **Brownfield** | System-level + existing test baseline | Regression hotspots, integration risks |
+| **Enterprise** | Compliance-aware testability | Security/performance/compliance focus |
 
 ## Tips
 
-- Run system-level test-design right after architecture
-- Run epic-level test-design at the start of each epic
-- Update test design if ADRs change
-- Use the output to guide `*atdd` and `*automate` workflows
+- **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`
 
----
+## Next Steps
 
-## Related
+After test design:
 
-- [TEA Overview](/docs/explanation/features/tea-overview.md) - Understanding the Test Architect
-- [Setup Test Framework](/docs/how-to/workflows/setup-test-framework.md) - Setting up testing infrastructure
-- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Architecture workflow
+1. **Setup Test Framework** — If not already configured
+2. **Implementation Readiness** — System-level feeds into gate check
+3. **Story Implementation** — Epic-level guides testing during dev

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

@@ -0,0 +1,605 @@
+---
+title: "How to Run Test Review with TEA"
+description: Audit test quality using TEA's comprehensive knowledge base and get 0-100 scoring
+---
+
+# How to Run Test Review with TEA
+
+Use TEA's `*test-review` workflow to audit test quality with objective scoring and actionable feedback. TEA reviews tests against its knowledge base of best practices.
+
+## When to Use This
+
+- Want to validate test quality objectively
+- Need quality metrics for release gates
+- Preparing for production deployment
+- Reviewing team-written tests
+- Auditing AI-generated tests
+- Onboarding new team members (show good patterns)
+
+## Prerequisites
+
+- BMad Method installed
+- TEA agent available
+- Tests written (to review)
+- Test framework configured
+
+## Steps
+
+### 1. Load TEA Agent
+
+Start a fresh chat and load TEA:
+
+```
+*tea
+```
+
+### 2. Run the Test Review Workflow
+
+```
+*test-review
+```
+
+### 3. Specify Review Scope
+
+TEA will ask what to review.
+
+#### Option A: Single File
+
+Review one test file:
+
+```
+tests/e2e/checkout.spec.ts
+```
+
+**Best for:**
+- Reviewing specific failing tests
+- Quick feedback on new tests
+- Learning from specific examples
+
+#### Option B: Directory
+
+Review all tests in a directory:
+
+```
+tests/e2e/
+```
+
+**Best for:**
+- Reviewing E2E test suite
+- Comparing test quality across files
+- Finding patterns of issues
+
+#### Option C: Entire Suite
+
+Review all tests:
+
+```
+tests/
+```
+
+**Best for:**
+- Release gate quality check
+- Comprehensive audit
+- Establishing baseline metrics
+
+### 4. Review the Quality Report
+
+TEA generates a comprehensive quality report with scoring.
+
+#### Report Structure (`test-review.md`):
+
+```markdown
+# Test Quality Review Report
+
+**Date:** 2026-01-13
+**Scope:** tests/e2e/
+**Overall Score:** 76/100
+
+## Summary
+
+- **Tests Reviewed:** 12
+- **Passing Quality:** 9 tests (75%)
+- **Needs Improvement:** 3 tests (25%)
+- **Critical Issues:** 2
+- **Recommendations:** 6
+
+## Critical Issues
+
+### 1. Hard Waits Detected
+
+**File:** `tests/e2e/checkout.spec.ts:45`
+**Issue:** Using `page.waitForTimeout(3000)`
+**Impact:** Test is flaky and unnecessarily slow
+**Severity:** Critical
+
+**Current Code:**
+```typescript
+await page.click('button[type="submit"]');
+await page.waitForTimeout(3000);  // ❌ Hard wait
+await expect(page.locator('.success')).toBeVisible();
+```
+
+**Fix:**
+```typescript
+await page.click('button[type="submit"]');
+// Wait for the API response that triggers success message
+await page.waitForResponse(resp =>
+  resp.url().includes('/api/checkout') && resp.ok()
+);
+await expect(page.locator('.success')).toBeVisible();
+```
+
+**Why This Matters:**
+- Hard waits are fixed timeouts that don't wait for actual conditions
+- Tests fail intermittently on slower machines
+- Wastes time waiting even when response is fast
+- Network-first patterns are more reliable
+
+---
+
+### 2. Conditional Flow Control
+
+**File:** `tests/e2e/profile.spec.ts:28`
+**Issue:** Using if/else to handle optional elements
+**Impact:** Non-deterministic test behavior
+**Severity:** Critical
+
+**Current Code:**
+```typescript
+if (await page.locator('.banner').isVisible()) {
+  await page.click('.dismiss');
+}
+// ❌ Test behavior changes based on banner presence
+```
+
+**Fix:**
+```typescript
+// Option 1: Make banner presence deterministic
+await expect(page.locator('.banner')).toBeVisible();
+await page.click('.dismiss');
+
+// Option 2: Test both scenarios separately
+test('should show banner for new users', async ({ page }) => {
+  // Test with banner
+});
+
+test('should not show banner for returning users', async ({ page }) => {
+  // Test without banner
+});
+```
+
+**Why This Matters:**
+- Tests should be deterministic (same result every run)
+- Conditionals hide bugs (what if banner should always show?)
+- Makes debugging harder
+- Violates test isolation principle
+
+## Recommendations
+
+### 1. Extract Repeated Setup
+
+**File:** `tests/e2e/profile.spec.ts`
+**Issue:** Login code duplicated in every test
+**Severity:** Medium
+**Impact:** Maintenance burden, test verbosity
+
+**Current:**
+```typescript
+test('test 1', async ({ page }) => {
+  await page.goto('/login');
+  await page.fill('[name="email"]', 'test@example.com');
+  await page.fill('[name="password"]', 'password');
+  await page.click('button[type="submit"]');
+  // Test logic...
+});
+
+test('test 2', async ({ page }) => {
+  // Same login code repeated
+});
+```
+
+**Fix (Vanilla Playwright):**
+```typescript
+// Create fixture in tests/support/fixtures/auth.ts
+import { test as base, Page } from '@playwright/test';
+
+export const test = base.extend<{ authenticatedPage: Page }>({
+  authenticatedPage: async ({ page }, use) => {
+    await page.goto('/login');
+    await page.getByLabel('Email').fill('test@example.com');
+    await page.getByLabel('Password').fill('password');
+    await page.getByRole('button', { name: 'Sign in' }).click();
+    await page.waitForURL(/\/dashboard/);
+    await use(page);
+  }
+});
+
+// Use in tests
+test('test 1', async ({ authenticatedPage }) => {
+  // Already logged in
+});
+```
+
+**Better (With Playwright Utils):**
+```typescript
+// Use built-in auth-session fixture
+import { test as base } from '@playwright/test';
+import { createAuthFixtures } from '@seontechnologies/playwright-utils/auth-session';
+
+export const test = base.extend(createAuthFixtures());
+
+// Use in tests - even simpler
+test('test 1', async ({ page, authToken }) => {
+  // authToken already available (persisted, reused)
+  await page.goto('/dashboard');
+  // Already authenticated via authToken
+});
+```
+
+**Playwright Utils Benefits:**
+- Token persisted to disk (faster subsequent runs)
+- Multi-user support out of the box
+- Automatic token renewal if expired
+- No manual login flow needed
+
+---
+
+### 2. Add Network Assertions
+
+**File:** `tests/e2e/api-calls.spec.ts`
+**Issue:** No verification of API responses
+**Severity:** Low
+**Impact:** Tests don't catch API errors
+
+**Current:**
+```typescript
+await page.click('button[name="save"]');
+await expect(page.locator('.success')).toBeVisible();
+// ❌ What if API returned 500 but UI shows cached success?
+```
+
+**Enhancement:**
+```typescript
+const responsePromise = page.waitForResponse(
+  resp => resp.url().includes('/api/profile') && resp.status() === 200
+);
+await page.click('button[name="save"]');
+const response = await responsePromise;
+
+// Verify API response
+const data = await response.json();
+expect(data.success).toBe(true);
+
+// Verify UI
+await expect(page.locator('.success')).toBeVisible();
+```
+
+---
+
+### 3. Improve Test Names
+
+**File:** `tests/e2e/checkout.spec.ts`
+**Issue:** Vague test names
+**Severity:** Low
+**Impact:** Hard to understand test purpose
+
+**Current:**
+```typescript
+test('should work', async ({ page }) => { });
+test('test checkout', async ({ page }) => { });
+```
+
+**Better:**
+```typescript
+test('should complete checkout with valid credit card', async ({ page }) => { });
+test('should show validation error for expired card', async ({ page }) => { });
+```
+
+## Quality Scores by Category
+
+| Category | Score | Target | Status |
+|----------|-------|--------|--------|
+| **Determinism** | 26/35 | 30/35 | ⚠️ Needs Improvement |
+| **Isolation** | 22/25 | 20/25 | ✅ Good |
+| **Assertions** | 18/20 | 16/20 | ✅ Good |
+| **Structure** | 7/10 | 8/10 | ⚠️ Minor Issues |
+| **Performance** | 3/10 | 8/10 | ❌ Critical |
+
+### Scoring Breakdown
+
+**Determinism (35 points max):**
+- No hard waits: 0/10 ❌ (found 3 instances)
+- No conditionals: 8/10 ⚠️ (found 2 instances)
+- No try-catch flow control: 10/10 ✅
+- Network-first patterns: 8/15 ⚠️ (some tests missing)
+
+**Isolation (25 points max):**
+- Self-cleaning: 20/20 ✅
+- No global state: 5/5 ✅
+- Parallel-safe: 0/0 ✅ (not tested)
+
+**Assertions (20 points max):**
+- Explicit in test body: 15/15 ✅
+- Specific and meaningful: 3/5 ⚠️ (some weak assertions)
+
+**Structure (10 points max):**
+- Test size < 300 lines: 5/5 ✅
+- Clear names: 2/5 ⚠️ (some vague names)
+
+**Performance (10 points max):**
+- Execution time < 1.5 min: 3/10 ❌ (3 tests exceed limit)
+
+## Files Reviewed
+
+| File | Score | Issues | Status |
+|------|-------|--------|--------|
+| `tests/e2e/checkout.spec.ts` | 65/100 | 4 | ❌ Needs Work |
+| `tests/e2e/profile.spec.ts` | 72/100 | 3 | ⚠️ Needs Improvement |
+| `tests/e2e/search.spec.ts` | 88/100 | 1 | ✅ Good |
+| `tests/api/profile.spec.ts` | 92/100 | 0 | ✅ Excellent |
+
+## Next Steps
+
+### Immediate (Fix Critical Issues)
+1. Remove hard waits in `checkout.spec.ts` (line 45, 67, 89)
+2. Fix conditional in `profile.spec.ts` (line 28)
+3. Optimize slow tests in `checkout.spec.ts`
+
+### Short-term (Apply Recommendations)
+4. Extract login fixture from `profile.spec.ts`
+5. Add network assertions to `api-calls.spec.ts`
+6. Improve test names in `checkout.spec.ts`
+
+### Long-term (Continuous Improvement)
+7. Re-run `*test-review` after fixes (target: 85/100)
+8. Add performance budgets to CI
+9. Document test patterns for team
+
+## Knowledge Base References
+
+TEA reviewed against these patterns:
+- [test-quality.md](/docs/reference/tea/knowledge-base.md#test-quality) - Execution limits, isolation
+- [network-first.md](/docs/reference/tea/knowledge-base.md#network-first) - Deterministic waits
+- [timing-debugging.md](/docs/reference/tea/knowledge-base.md#timing-debugging) - Race conditions
+- [selector-resilience.md](/docs/reference/tea/knowledge-base.md#selector-resilience) - Robust selectors
+```
+
+## Understanding the Scores
+
+### What Do Scores Mean?
+
+| Score Range | Interpretation | Action |
+|-------------|----------------|--------|
+| **90-100** | Excellent | Minimal changes needed, production-ready |
+| **80-89** | Good | Minor improvements recommended |
+| **70-79** | Acceptable | Address recommendations before release |
+| **60-69** | Needs Improvement | Fix critical issues, apply recommendations |
+| **< 60** | Critical | Significant refactoring needed |
+
+### Scoring Criteria
+
+**Determinism (35 points):**
+- Tests produce same result every run
+- No random failures (flakiness)
+- No environment-dependent behavior
+
+**Isolation (25 points):**
+- Tests don't depend on each other
+- Can run in any order
+- Clean up after themselves
+
+**Assertions (20 points):**
+- Verify actual behavior
+- Specific and meaningful
+- Not abstracted away in helpers
+
+**Structure (10 points):**
+- Readable and maintainable
+- Appropriate size
+- Clear naming
+
+**Performance (10 points):**
+- Fast execution
+- Efficient selectors
+- No unnecessary waits
+
+## What You Get
+
+### Quality Report
+- Overall score (0-100)
+- Category scores (Determinism, Isolation, etc.)
+- File-by-file breakdown
+
+### Critical Issues
+- Specific line numbers
+- Code examples (current vs fixed)
+- Why it matters explanation
+- Impact assessment
+
+### Recommendations
+- Actionable improvements
+- Code examples
+- Priority/severity levels
+
+### Next Steps
+- Immediate actions (fix critical)
+- Short-term improvements
+- Long-term quality goals
+
+## Tips
+
+### Review Before Release
+
+Make test review part of release checklist:
+
+```markdown
+## Release Checklist
+- [ ] All tests passing
+- [ ] Test review score > 80
+- [ ] Critical issues resolved
+- [ ] Performance within budget
+```
+
+### Review After AI Generation
+
+Always review AI-generated tests:
+
+```
+1. Run *atdd or *automate
+2. Run *test-review on generated tests
+3. Fix critical issues
+4. Commit tests
+```
+
+### Set Quality Gates
+
+Use scores as quality gates:
+
+```yaml
+# .github/workflows/test.yml
+- name: Review test quality
+  run: |
+    # Run test review
+    # Parse score from report
+    if [ $SCORE -lt 80 ]; then
+      echo "Test quality below threshold"
+      exit 1
+    fi
+```
+
+### Review Regularly
+
+Schedule periodic reviews:
+
+- **Per story:** Optional (spot check new tests)
+- **Per epic:** Recommended (ensure consistency)
+- **Per release:** Recommended for quality gates (required if using formal gate process)
+- **Quarterly:** Audit entire suite
+
+### Focus Reviews
+
+For large suites, review incrementally:
+
+**Week 1:** Review E2E tests
+**Week 2:** Review API tests
+**Week 3:** Review component tests (Cypress CT or Vitest)
+**Week 4:** Apply fixes across all suites
+
+**Component Testing Note:** TEA reviews component tests using framework-specific knowledge:
+- **Cypress:** Reviews Cypress Component Testing specs (*.cy.tsx)
+- **Playwright:** Reviews Vitest component tests (*.test.tsx)
+
+### Use Reviews for Learning
+
+Share reports with team:
+
+```
+Team Meeting:
+- Review test-review.md
+- Discuss critical issues
+- Agree on patterns
+- Update team guidelines
+```
+
+### Compare Over Time
+
+Track improvement:
+
+```markdown
+## Quality Trend
+
+| Date | Score | Critical Issues | Notes |
+|------|-------|-----------------|-------|
+| 2026-01-01 | 65 | 5 | Baseline |
+| 2026-01-15 | 72 | 2 | Fixed hard waits |
+| 2026-02-01 | 84 | 0 | All critical resolved |
+```
+
+## Common Issues
+
+### Low Determinism Score
+
+**Symptoms:**
+- Tests fail randomly
+- "Works on my machine"
+- CI failures that don't reproduce locally
+
+**Common Causes:**
+- Hard waits (`waitForTimeout`)
+- Conditional flow control (`if/else`)
+- Try-catch for flow control
+- Missing network-first patterns
+
+**Fix:** Review determinism section, apply network-first patterns
+
+### Low Performance Score
+
+**Symptoms:**
+- Tests take > 1.5 minutes each
+- Test suite takes hours
+- CI times out
+
+**Common Causes:**
+- Unnecessary waits (hard timeouts)
+- Inefficient selectors (XPath, complex CSS)
+- Not using parallelization
+- Heavy setup in every test
+
+**Fix:** Optimize waits, improve selectors, use fixtures
+
+### Low Isolation Score
+
+**Symptoms:**
+- Tests fail when run in different order
+- Tests fail in parallel
+- Test data conflicts
+
+**Common Causes:**
+- Shared global state
+- Tests don't clean up
+- Hard-coded test data
+- Database not reset between tests
+
+**Fix:** Use fixtures, clean up in afterEach, use unique test data
+
+### "Too Many Issues to Fix"
+
+**Problem:** Report shows 50+ issues, overwhelming.
+
+**Solution:** Prioritize:
+1. Fix all critical issues first
+2. Apply top 3 recommendations
+3. Re-run review
+4. Iterate
+
+Don't try to fix everything at once.
+
+### Reviews Take Too Long
+
+**Problem:** Reviewing entire suite takes hours.
+
+**Solution:** Review incrementally:
+- Review new tests in PR review
+- Schedule directory reviews weekly
+- Full suite review quarterly
+
+## Related Guides
+
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md) - Generate tests to review
+- [How to Run Automate](/docs/how-to/workflows/run-automate.md) - Expand coverage to review
+- [How to Run Trace](/docs/how-to/workflows/run-trace.md) - Coverage complements quality
+
+## Understanding the Concepts
+
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - What makes tests good
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Avoiding flakiness
+- [Fixture Architecture](/docs/explanation/tea/fixture-architecture.md) - Reusable patterns
+
+## Reference
+
+- [Command: *test-review](/docs/reference/tea/commands.md#test-review) - Full command reference
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - Patterns TEA reviews against
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/workflows/run-trace.md

@@ -0,0 +1,883 @@
+---
+title: "How to Run Trace with TEA"
+description: Map requirements to tests and make quality gate decisions using TEA's trace workflow
+---
+
+# How to Run Trace with TEA
+
+Use TEA's `*trace` workflow for requirements traceability and quality gate decisions. This is a two-phase workflow: Phase 1 analyzes coverage, Phase 2 makes the go/no-go decision.
+
+## When to Use This
+
+### Phase 1: Requirements Traceability
+- Map acceptance criteria to implemented tests
+- Identify coverage gaps
+- Prioritize missing tests
+- Refresh coverage after each story/epic
+
+### Phase 2: Quality Gate Decision
+- Make go/no-go decision for release
+- Validate coverage meets thresholds
+- Document gate decision with evidence
+- Support business-approved waivers
+
+## Prerequisites
+
+- BMad Method installed
+- TEA agent available
+- Requirements defined (stories, acceptance criteria, test design)
+- Tests implemented
+- For brownfield: Existing codebase with tests
+
+## Steps
+
+### 1. Run the Trace Workflow
+
+```
+*trace
+```
+
+### 2. Specify Phase
+
+TEA will ask which phase you're running.
+
+**Phase 1: Requirements Traceability**
+- Analyze coverage
+- Identify gaps
+- Generate recommendations
+
+**Phase 2: Quality Gate Decision**
+- Make PASS/CONCERNS/FAIL/WAIVED decision
+- Requires Phase 1 complete
+
+**Typical flow:** Run Phase 1 first, review gaps, then run Phase 2 for gate decision.
+
+---
+
+## Phase 1: Requirements Traceability
+
+### 3. Provide Requirements Source
+
+TEA will ask where requirements are defined.
+
+**Options:**
+
+| Source          | Example                       | Best For               |
+| --------------- | ----------------------------- | ---------------------- |
+| **Story file**  | `story-profile-management.md` | Single story coverage  |
+| **Test design** | `test-design-epic-1.md`       | Epic coverage          |
+| **PRD**         | `PRD.md`                      | System-level coverage  |
+| **Multiple**    | All of the above              | Comprehensive analysis |
+
+**Example Response:**
+```
+Requirements:
+- story-profile-management.md (acceptance criteria)
+- test-design-epic-1.md (test priorities)
+```
+
+### 4. Specify Test Location
+
+TEA will ask where tests are located.
+
+**Example:**
+```
+Test location: tests/
+Include:
+- tests/api/
+- tests/e2e/
+```
+
+### 5. Specify Focus Areas (Optional)
+
+**Example:**
+```
+Focus on:
+- Profile CRUD operations
+- Validation scenarios
+- Authorization checks
+```
+
+### 6. Review Coverage Matrix
+
+TEA generates a comprehensive traceability matrix.
+
+#### Traceability Matrix (`traceability-matrix.md`):
+
+```markdown
+# Requirements Traceability Matrix
+
+**Date:** 2026-01-13
+**Scope:** Epic 1 - User Profile Management
+**Phase:** Phase 1 (Traceability Analysis)
+
+## Coverage Summary
+
+| Metric                 | Count | Percentage |
+| ---------------------- | ----- | ---------- |
+| **Total Requirements** | 15    | 100%       |
+| **Full Coverage**      | 11    | 73%        |
+| **Partial Coverage**   | 3     | 20%        |
+| **No Coverage**        | 1     | 7%         |
+
+### By Priority
+
+| Priority | Total | Covered | Percentage        |
+| -------- | ----- | ------- | ----------------- |
+| **P0**   | 5     | 5       | 100% ✅            |
+| **P1**   | 6     | 5       | 83% ⚠️             |
+| **P2**   | 3     | 1       | 33% ⚠️             |
+| **P3**   | 1     | 0       | 0% ✅ (acceptable) |
+
+---
+
+## Detailed Traceability
+
+### ✅ Requirement 1: User can view their profile (P0)
+
+**Acceptance Criteria:**
+- User navigates to /profile
+- Profile displays name, email, avatar
+- Data is current (not cached)
+
+**Test Coverage:** FULL ✅
+
+**Tests:**
+- `tests/e2e/profile-view.spec.ts:15` - "should display profile page with current data"
+  - ✅ Navigates to /profile
+  - ✅ Verifies name, email visible
+  - ✅ Verifies avatar displayed
+  - ✅ Validates data freshness via API assertion
+
+- `tests/api/profile.spec.ts:8` - "should fetch user profile via API"
+  - ✅ Calls GET /api/profile
+  - ✅ Validates response schema
+  - ✅ Confirms all fields present
+
+---
+
+### ⚠️ Requirement 2: User can edit profile (P0)
+
+**Acceptance Criteria:**
+- User clicks "Edit Profile"
+- Can modify name, email, bio
+- Can upload avatar
+- Changes are persisted
+- Success message shown
+
+**Test Coverage:** PARTIAL ⚠️
+
+**Tests:**
+- `tests/e2e/profile-edit.spec.ts:22` - "should edit and save profile"
+  - ✅ Clicks edit button
+  - ✅ Modifies name and email
+  - ⚠️ **Does NOT test bio field**
+  - ❌ **Does NOT test avatar upload**
+  - ✅ Verifies persistence
+  - ✅ Verifies success message
+
+- `tests/api/profile.spec.ts:25` - "should update profile via PATCH"
+  - ✅ Calls PATCH /api/profile
+  - ✅ Validates update response
+  - ⚠️ **Only tests name/email, not bio/avatar**
+
+**Missing Coverage:**
+- Bio field not tested in E2E or API
+- Avatar upload not tested
+
+**Gap Severity:** HIGH (P0 requirement, critical path)
+
+---
+
+### ✅ Requirement 3: Invalid email shows validation error (P1)
+
+**Acceptance Criteria:**
+- Enter invalid email format
+- See error message
+- Cannot save changes
+
+**Test Coverage:** FULL ✅
+
+**Tests:**
+- `tests/e2e/profile-edit.spec.ts:45` - "should show validation error for invalid email"
+- `tests/api/profile.spec.ts:50` - "should return 400 for invalid email"
+
+---
+
+### ❌ Requirement 15: Profile export as PDF (P2)
+
+**Acceptance Criteria:**
+- User clicks "Export Profile"
+- PDF downloads with profile data
+
+**Test Coverage:** NONE ❌
+
+**Gap Analysis:**
+- **Priority:** P2 (medium)
+- **Risk:** Low (non-critical feature)
+- **Recommendation:** Add in next iteration (not blocking for release)
+
+---
+
+## Gap Prioritization
+
+### Critical Gaps (Must Fix Before Release)
+
+| Gap | Requirement              | Priority | Risk | Recommendation      |
+| --- | ------------------------ | -------- | ---- | ------------------- |
+| 1   | Bio field not tested     | P0       | High | Add E2E + API tests |
+| 2   | Avatar upload not tested | P0       | High | Add E2E + API tests |
+
+**Estimated Effort:** 3 hours
+**Owner:** QA team
+**Deadline:** Before release
+
+### Non-Critical Gaps (Can Defer)
+
+| Gap | Requirement               | Priority | Risk | Recommendation      |
+| --- | ------------------------- | -------- | ---- | ------------------- |
+| 3   | Profile export not tested | P2       | Low  | Add in v1.3 release |
+
+**Estimated Effort:** 2 hours
+**Owner:** QA team
+**Deadline:** Next release (February)
+
+---
+
+## Recommendations
+
+### 1. Add Bio Field Tests
+
+**Tests Needed (Vanilla Playwright):**
+```typescript
+// tests/e2e/profile-edit.spec.ts
+test('should edit bio field', async ({ page }) => {
+  await page.goto('/profile');
+  await page.getByRole('button', { name: 'Edit' }).click();
+  await page.getByLabel('Bio').fill('New bio text');
+  await page.getByRole('button', { name: 'Save' }).click();
+  await expect(page.getByText('New bio text')).toBeVisible();
+});
+
+// tests/api/profile.spec.ts
+test('should update bio via API', async ({ request }) => {
+  const response = await request.patch('/api/profile', {
+    data: { bio: 'Updated bio' }
+  });
+  expect(response.ok()).toBeTruthy();
+  const { bio } = await response.json();
+  expect(bio).toBe('Updated bio');
+});
+```
+
+**With Playwright Utils:**
+```typescript
+// tests/e2e/profile-edit.spec.ts
+import { test } from '../support/fixtures';  // Composed with authToken
+
+test('should edit bio field', async ({ page, authToken }) => {
+  await page.goto('/profile');
+  await page.getByRole('button', { name: 'Edit' }).click();
+  await page.getByLabel('Bio').fill('New bio text');
+  await page.getByRole('button', { name: 'Save' }).click();
+  await expect(page.getByText('New bio text')).toBeVisible();
+});
+
+// tests/api/profile.spec.ts
+import { test as base, expect } from '@playwright/test';
+import { test as apiRequestFixture } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { createAuthFixtures } from '@seontechnologies/playwright-utils/auth-session';
+import { mergeTests } from '@playwright/test';
+
+// Merge API request + auth fixtures
+const authFixtureTest = base.extend(createAuthFixtures());
+const test = mergeTests(apiRequestFixture, authFixtureTest);
+
+test('should update bio via API', async ({ apiRequest, authToken }) => {
+  const { status, body } = await apiRequest({
+    method: 'PATCH',
+    path: '/api/profile',
+    body: { bio: 'Updated bio' },  
+    headers: { Authorization: `Bearer ${authToken}` }
+  });
+
+  expect(status).toBe(200);
+  expect(body.bio).toBe('Updated bio');
+});
+```
+
+**Note:** `authToken` requires auth-session fixture setup. See [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md#auth-session).
+
+### 2. Add Avatar Upload Tests
+
+**Tests Needed:**
+```typescript
+// tests/e2e/profile-edit.spec.ts
+test('should upload avatar image', async ({ page }) => {
+  await page.goto('/profile');
+  await page.getByRole('button', { name: 'Edit' }).click();
+
+  // Upload file
+  await page.setInputFiles('[type="file"]', 'fixtures/avatar.png');
+  await page.getByRole('button', { name: 'Save' }).click();
+
+  // Verify uploaded image displays
+  await expect(page.locator('img[alt="Profile avatar"]')).toBeVisible();
+});
+
+// tests/api/profile.spec.ts
+import { test, expect } from '@playwright/test';
+import fs from 'fs/promises';
+
+test('should accept valid image upload', async ({ request }) => {
+  const response = await request.post('/api/profile/avatar', {
+    multipart: {
+      file: {
+        name: 'avatar.png',
+        mimeType: 'image/png',
+        buffer: await fs.readFile('fixtures/avatar.png')
+      }
+    }
+  });
+  expect(response.ok()).toBeTruthy();
+});
+```
+
+---
+
+## Next Steps
+
+After reviewing traceability:
+
+1. **Fix critical gaps** - Add tests for P0/P1 requirements
+2. **Run *test-review** - Ensure new tests meet quality standards
+3. **Run Phase 2** - Make gate decision after gaps addressed
+```
+
+---
+
+## Phase 2: Quality Gate Decision
+
+After Phase 1 coverage analysis is complete, run Phase 2 for the gate decision.
+
+**Prerequisites:**
+- Phase 1 traceability matrix complete
+- Test execution results available (must have test results)
+
+**Note:** Phase 2 will skip if test execution results aren't provided. The workflow requires actual test run results to make gate decisions.
+
+### 7. Run Phase 2
+
+```
+*trace
+```
+
+Select "Phase 2: Quality Gate Decision"
+
+### 8. Provide Additional Context
+
+TEA will ask for:
+
+**Gate Type:**
+- Story gate (small release)
+- Epic gate (larger release)
+- Release gate (production deployment)
+- Hotfix gate (emergency fix)
+
+**Decision Mode:**
+- **Deterministic** - Rule-based (coverage %, quality scores)
+- **Manual** - Team decision with TEA guidance
+
+**Example:**
+```
+Gate type: Epic gate
+Decision mode: Deterministic
+```
+
+### 9. Provide Supporting Evidence
+
+TEA will request:
+
+**Phase 1 Results:**
+```
+traceability-matrix.md (from Phase 1)
+```
+
+**Test Quality (Optional):**
+```
+test-review.md (from *test-review)
+```
+
+**NFR Assessment (Optional):**
+```
+nfr-assessment.md (from *nfr-assess)
+```
+
+### 10. Review Gate Decision
+
+TEA makes evidence-based gate decision and writes to separate file.
+
+#### Gate Decision (`gate-decision-{gate_type}-{story_id}.md`):
+
+```markdown
+---
+
+# Phase 2: Quality Gate Decision
+
+**Gate Type:** Epic Gate
+**Decision:** PASS ✅
+**Date:** 2026-01-13
+**Approvers:** Product Manager, Tech Lead, QA Lead
+
+## Decision Summary
+
+**Verdict:** Ready to release
+
+**Evidence:**
+- P0 coverage: 100% (5/5 requirements)
+- P1 coverage: 100% (6/6 requirements)
+- P2 coverage: 33% (1/3 requirements) - acceptable
+- Test quality score: 84/100
+- NFR assessment: PASS
+
+## Coverage Analysis
+
+| Priority | Required Coverage | Actual Coverage | Status                |
+| -------- | ----------------- | --------------- | --------------------- |
+| **P0**   | 100%              | 100%            | ✅ PASS                |
+| **P1**   | 90%               | 100%            | ✅ PASS                |
+| **P2**   | 50%               | 33%             | ⚠️ Below (acceptable)  |
+| **P3**   | 20%               | 0%              | ✅ PASS (low priority) |
+
+**Rationale:**
+- All critical path (P0) requirements fully tested
+- All high-value (P1) requirements fully tested
+- P2 gap (profile export) is low risk and deferred to next release
+
+## Quality Metrics
+
+| Metric             | Threshold | Actual | Status |
+| ------------------ | --------- | ------ | ------ |
+| P0/P1 Coverage     | >95%      | 100%   | ✅      |
+| Test Quality Score | >80       | 84     | ✅      |
+| NFR Status         | PASS      | PASS   | ✅      |
+
+## Risks and Mitigations
+
+### Accepted Risks
+
+**Risk 1: Profile export not tested (P2)**
+- **Impact:** Medium (users can't export profile)
+- **Mitigation:** Feature flag disabled by default
+- **Plan:** Add tests in v1.3 release (February)
+- **Monitoring:** Track feature flag usage
+
+## Approvals
+
+- [x] **Product Manager** - Business requirements met (Approved: 2026-01-13)
+- [x] **Tech Lead** - Technical quality acceptable (Approved: 2026-01-13)
+- [x] **QA Lead** - Test coverage sufficient (Approved: 2026-01-13)
+
+## Next Steps
+
+### Deployment
+1. Merge to main branch
+2. Deploy to staging
+3. Run smoke tests in staging
+4. Deploy to production
+5. Monitor for 24 hours
+
+### Monitoring
+- Set alerts for profile endpoint (P99 > 200ms)
+- Track error rates (target: <0.1%)
+- Monitor profile export feature flag usage
+
+### Future Work
+- Add profile export tests (v1.3)
+- Expand P2 coverage to 50%
+```
+
+### Gate Decision Rules
+
+TEA uses deterministic rules when decision_mode = "deterministic":
+
+| P0 Coverage | P1 Coverage | Overall Coverage | Decision                     |
+| ----------- | ----------- | ---------------- | ---------------------------- |
+| 100%        | ≥90%        | ≥80%             | **PASS** ✅                   |
+| 100%        | 80-89%      | ≥80%             | **CONCERNS** ⚠️               |
+| <100%       | Any         | Any              | **FAIL** ❌                   |
+| Any         | <80%        | Any              | **FAIL** ❌                   |
+| Any         | Any         | <80%             | **FAIL** ❌                   |
+| Any         | Any         | Any              | **WAIVED** ⏭️ (with approval) |
+
+**Detailed Rules:**
+- **PASS:** P0=100%, P1≥90%, Overall≥80%
+- **CONCERNS:** P0=100%, P1 80-89%, Overall≥80% (below threshold but not critical)
+- **FAIL:** P0<100% OR P1<80% OR Overall<80% (critical gaps)
+
+**PASS** ✅: All criteria met, ready to release
+
+**CONCERNS** ⚠️: Some criteria not met, but:
+- Mitigation plan exists
+- Risk is acceptable
+- Team approves proceeding
+- Monitoring in place
+
+**FAIL** ❌: Critical criteria not met:
+- P0 requirements not tested
+- Critical security vulnerabilities
+- System is broken
+- Cannot deploy
+
+**WAIVED** ⏭️: Business approves proceeding despite concerns:
+- Documented business justification
+- Accepted risks quantified
+- Approver signatures
+- Future plans documented
+
+### Example CONCERNS Decision
+
+```markdown
+## Decision Summary
+
+**Verdict:** CONCERNS ⚠️ - Proceed with monitoring
+
+**Evidence:**
+- P0 coverage: 100%
+- P1 coverage: 85% (below 90% target)
+- Test quality: 78/100 (below 80 target)
+
+**Gaps:**
+- 1 P1 requirement not tested (avatar upload)
+- Test quality score slightly below threshold
+
+**Mitigation:**
+- Avatar upload not critical for v1.2 launch
+- Test quality issues are minor (no flakiness)
+- Monitoring alerts configured
+
+**Approvals:**
+- Product Manager: APPROVED (business priority to launch)
+- Tech Lead: APPROVED (technical risk acceptable)
+```
+
+### Example FAIL Decision
+
+```markdown
+## Decision Summary
+
+**Verdict:** FAIL ❌ - Cannot release
+
+**Evidence:**
+- P0 coverage: 60% (below 95% threshold)
+- Critical security vulnerability (CVE-2024-12345)
+- Test quality: 55/100
+
+**Blockers:**
+1. **Login flow not tested** (P0 requirement)
+   - Critical path completely untested
+   - Must add E2E and API tests
+
+2. **SQL injection vulnerability**
+   - Critical security issue
+   - Must fix before deployment
+
+**Actions Required:**
+1. Add login tests (QA team, 2 days)
+2. Fix SQL injection (backend team, 1 day)
+3. Re-run security scan (DevOps, 1 hour)
+4. Re-run *trace after fixes
+
+**Cannot proceed until all blockers resolved.**
+```
+
+## What You Get
+
+### Phase 1: Traceability Matrix
+- Requirement-to-test mapping
+- Coverage classification (FULL/PARTIAL/NONE)
+- Gap identification with priorities
+- Actionable recommendations
+
+### Phase 2: Gate Decision
+- Go/no-go verdict (PASS/CONCERNS/FAIL/WAIVED)
+- Evidence summary
+- Approval signatures
+- Next steps and monitoring plan
+
+## Usage Patterns
+
+### Greenfield Projects
+
+**Phase 3:**
+```
+After architecture complete:
+1. Run *test-design (system-level)
+2. Run *trace Phase 1 (baseline)
+3. Use for implementation-readiness gate
+```
+
+**Phase 4:**
+```
+After each epic/story:
+1. Run *trace Phase 1 (refresh coverage)
+2. Identify gaps
+3. Add missing tests
+```
+
+**Release Gate:**
+```
+Before deployment:
+1. Run *trace Phase 1 (final coverage check)
+2. Run *trace Phase 2 (make gate decision)
+3. Get approvals
+4. Deploy (if PASS or WAIVED)
+```
+
+### Brownfield Projects
+
+**Phase 2:**
+```
+Before planning new work:
+1. Run *trace Phase 1 (establish baseline)
+2. Understand existing coverage
+3. Plan testing strategy
+```
+
+**Phase 4:**
+```
+After each epic/story:
+1. Run *trace Phase 1 (refresh)
+2. Compare to baseline
+3. Track coverage improvement
+```
+
+**Release Gate:**
+```
+Before deployment:
+1. Run *trace Phase 1 (final check)
+2. Run *trace Phase 2 (gate decision)
+3. Compare to baseline
+4. Deploy if coverage maintained or improved
+```
+
+## Tips
+
+### Run Phase 1 Frequently
+
+Don't wait until release gate:
+
+```
+After Story 1: *trace Phase 1 (identify gaps early)
+After Story 2: *trace Phase 1 (refresh)
+After Story 3: *trace Phase 1 (refresh)
+Before Release: *trace Phase 1 + Phase 2 (final gate)
+```
+
+**Benefit:** Catch gaps early when they're cheap to fix.
+
+### Use Coverage Trends
+
+Track improvement over time:
+
+```markdown
+## Coverage Trend
+
+| Date       | Epic     | P0/P1 Coverage | Quality Score | Status         |
+| ---------- | -------- | -------------- | ------------- | -------------- |
+| 2026-01-01 | Baseline | 45%            | -             | Starting point |
+| 2026-01-08 | Epic 1   | 78%            | 72            | Improving      |
+| 2026-01-15 | Epic 2   | 92%            | 84            | Near target    |
+| 2026-01-20 | Epic 3   | 100%           | 88            | Ready!         |
+```
+
+### Set Coverage Targets by Priority
+
+Don't aim for 100% across all priorities:
+
+**Recommended Targets:**
+- **P0:** 100% (critical path must be tested)
+- **P1:** 90% (high-value scenarios)
+- **P2:** 50% (nice-to-have features)
+- **P3:** 20% (low-value edge cases)
+
+### Use Classification Strategically
+
+**FULL** ✅: Requirement completely tested
+- E2E test covers full user workflow
+- API test validates backend behavior
+- All acceptance criteria covered
+
+**PARTIAL** ⚠️: Some aspects tested
+- E2E test exists but missing scenarios
+- API test exists but incomplete
+- Some acceptance criteria not covered
+
+**NONE** ❌: No tests exist
+- Requirement identified but not tested
+- May be intentional (low priority) or oversight
+
+**Classification helps prioritize:**
+- Fix NONE coverage for P0/P1 requirements first
+- Enhance PARTIAL coverage for P0 requirements
+- Accept PARTIAL or NONE for P2/P3 if time-constrained
+
+### Automate Gate Decisions
+
+Use traceability in CI:
+
+```yaml
+# .github/workflows/gate-check.yml
+- name: Check coverage
+  run: |
+    # Run trace Phase 1
+    # Parse coverage percentages
+    if [ $P0_COVERAGE -lt 95 ]; then
+      echo "P0 coverage below 95%"
+      exit 1
+    fi
+```
+
+### Document Waivers Clearly
+
+If proceeding with WAIVED:
+
+**Required:**
+```markdown
+## Waiver Documentation
+
+**Waived By:** VP Engineering, Product Lead
+**Date:** 2026-01-15
+**Gate Type:** Release Gate v1.2
+
+**Justification:**
+Business critical to launch by Q1 for investor demo.
+Performance concerns acceptable for initial user base.
+
+**Conditions:**
+- Set monitoring alerts for P99 > 300ms
+- Plan optimization for v1.3 (due February 28)
+- Monitor user feedback closely
+
+**Accepted Risks:**
+- 1% of users may experience 350ms latency
+- Avatar upload feature incomplete
+- Profile export deferred to next release
+
+**Quantified Impact:**
+- Affects <100 users at current scale
+- Workaround exists (manual export)
+- Monitoring will catch issues early
+
+**Approvals:**
+- VP Engineering: [Signature] Date: 2026-01-15
+- Product Lead: [Signature] Date: 2026-01-15
+- QA Lead: [Signature] Date: 2026-01-15
+```
+
+## Common Issues
+
+### Too Many Gaps to Fix
+
+**Problem:** Phase 1 shows 50 uncovered requirements.
+
+**Solution:** Prioritize ruthlessly:
+1. Fix all P0 gaps (critical path)
+2. Fix high-risk P1 gaps
+3. Accept low-risk P1 gaps with mitigation
+4. Defer all P2/P3 gaps
+
+**Don't try to fix everything** - focus on what matters for release.
+
+### Can't Find Test Coverage
+
+**Problem:** Tests exist but TEA can't map them to requirements.
+
+**Cause:** Tests don't reference requirements.
+
+**Solution:** Add traceability comments:
+```typescript
+test('should display profile', async ({ page }) => {
+  // Covers: Requirement 1 - User can view profile
+  // Acceptance criteria: Navigate to /profile, see name/email
+  await page.goto('/profile');
+  await expect(page.getByText('Test User')).toBeVisible();
+});
+```
+
+Or use test IDs:
+```typescript
+test('[REQ-1] should display profile', async ({ page }) => {
+  // Test code...
+});
+```
+
+### Unclear What "FULL" vs "PARTIAL" Means
+
+**FULL** ✅: All acceptance criteria tested
+```
+Requirement: User can edit profile
+Acceptance criteria:
+  - Can modify name ✅ Tested
+  - Can modify email ✅ Tested
+  - Can upload avatar ✅ Tested
+  - Changes persist ✅ Tested
+Result: FULL coverage
+```
+
+**PARTIAL** ⚠️: Some criteria tested, some not
+```
+Requirement: User can edit profile
+Acceptance criteria:
+  - Can modify name ✅ Tested
+  - Can modify email ✅ Tested
+  - Can upload avatar ❌ Not tested
+  - Changes persist ✅ Tested
+Result: PARTIAL coverage (3/4 criteria)
+```
+
+### Gate Decision Unclear
+
+**Problem:** Not sure if PASS or CONCERNS is appropriate.
+
+**Guideline:**
+
+**Use PASS** ✅ if:
+- All P0 requirements 100% covered
+- P1 requirements >90% covered
+- No critical issues
+- NFRs met
+
+**Use CONCERNS** ⚠️ if:
+- P1 coverage 85-90% (close to threshold)
+- Minor quality issues (score 70-79)
+- NFRs have mitigation plans
+- Team agrees risk is acceptable
+
+**Use FAIL** ❌ if:
+- P0 coverage <100% (critical path gaps)
+- P1 coverage <85%
+- Critical security/performance issues
+- No mitigation possible
+
+**When in doubt, use CONCERNS** and document the risk.
+
+## Related Guides
+
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md) - Provides requirements for traceability
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md) - Quality scores feed gate
+- [How to Run NFR Assessment](/docs/how-to/workflows/run-nfr-assess.md) - NFR status feeds gate
+
+## Understanding the Concepts
+
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - Why P0 vs P3 matters
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Gate decisions in context
+
+## Reference
+
+- [Command: *trace](/docs/reference/tea/commands.md#trace) - Full command reference
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Config options
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/workflows/setup-ci.md

@@ -0,0 +1,712 @@
+---
+title: "How to Set Up CI Pipeline with TEA"
+description: Configure automated test execution with selective testing and burn-in loops using TEA
+---
+
+# How to Set Up CI Pipeline with TEA
+
+Use TEA's `*ci` workflow to scaffold production-ready CI/CD configuration for automated test execution with selective testing, parallel sharding, and flakiness detection.
+
+## When to Use This
+
+- Need to automate test execution in CI/CD
+- Want selective testing (only run affected tests)
+- Need parallel execution for faster feedback
+- Want burn-in loops for flakiness detection
+- Setting up new CI/CD pipeline
+- Optimizing existing CI/CD workflow
+
+## Prerequisites
+
+- BMad Method installed
+- TEA agent available
+- Test framework configured (run `*framework` first)
+- Tests written (have something to run in CI)
+- CI/CD platform access (GitHub Actions, GitLab CI, etc.)
+
+## Steps
+
+### 1. Load TEA Agent
+
+Start a fresh chat and load TEA:
+
+```
+*tea
+```
+
+### 2. Run the CI Workflow
+
+```
+*ci
+```
+
+### 3. Select CI/CD Platform
+
+TEA will ask which platform you're using.
+
+**Supported Platforms:**
+- **GitHub Actions** (most common)
+- **GitLab CI**
+- **Circle CI**
+- **Jenkins**
+- **Other** (TEA provides generic template)
+
+**Example:**
+```
+GitHub Actions
+```
+
+### 4. Configure Test Strategy
+
+TEA will ask about your test execution strategy.
+
+#### Repository Structure
+
+**Question:** "What's your repository structure?"
+
+**Options:**
+- **Single app** - One application in root
+- **Monorepo** - Multiple apps/packages
+- **Monorepo with affected detection** - Only test changed packages
+
+**Example:**
+```
+Monorepo with multiple apps
+Need selective testing for changed packages only
+```
+
+#### Parallel Execution
+
+**Question:** "Want to shard tests for parallel execution?"
+
+**Options:**
+- **No sharding** - Run tests sequentially
+- **Shard by workers** - Split across N workers
+- **Shard by file** - Each file runs in parallel
+
+**Example:**
+```
+Yes, shard across 4 workers for faster execution
+```
+
+**Why Shard?**
+- **4 workers:** 20-minute suite → 5 minutes
+- **Better resource usage:** Utilize CI runners efficiently
+- **Faster feedback:** Developers wait less
+
+#### Burn-In Loops
+
+**Question:** "Want burn-in loops for flakiness detection?"
+
+**Options:**
+- **No burn-in** - Run tests once
+- **PR burn-in** - Run tests multiple times on PRs
+- **Nightly burn-in** - Dedicated flakiness detection job
+
+**Example:**
+```
+Yes, run tests 5 times on PRs to catch flaky tests early
+```
+
+**Why Burn-In?**
+- Catches flaky tests before they merge
+- Prevents intermittent CI failures
+- Builds confidence in test suite
+
+### 5. Review Generated CI Configuration
+
+TEA generates platform-specific workflow files.
+
+#### GitHub Actions (`.github/workflows/test.yml`):
+
+```yaml
+name: Test Suite
+
+on:
+  pull_request:
+  push:
+    branches: [main, develop]
+  schedule:
+    - cron: '0 2 * * *'  # Nightly at 2 AM
+
+jobs:
+  # Main test job with sharding
+  test:
+    name: Test (Shard ${{ matrix.shard }})
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+
+    strategy:
+      fail-fast: false
+      matrix:
+        shard: [1, 2, 3, 4]
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version-file: '.nvmrc'
+          cache: 'npm'
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Install Playwright browsers
+        run: npx playwright install --with-deps
+
+      - name: Run tests
+        run: npx playwright test --shard=${{ matrix.shard }}/4
+
+      - name: Upload test results
+        if: always()
+        uses: actions/upload-artifact@v4
+        with:
+          name: test-results-${{ matrix.shard }}
+          path: test-results/
+          retention-days: 7
+
+      - name: Upload test report
+        if: always()
+        uses: actions/upload-artifact@v4
+        with:
+          name: playwright-report-${{ matrix.shard }}
+          path: playwright-report/
+          retention-days: 7
+
+  # Burn-in job for flakiness detection (PRs only)
+  burn-in:
+    name: Burn-In (Flakiness Detection)
+    runs-on: ubuntu-latest
+    if: github.event_name == 'pull_request'
+    timeout-minutes: 30
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version-file: '.nvmrc'
+          cache: 'npm'
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Install Playwright browsers
+        run: npx playwright install --with-deps
+
+      - name: Run burn-in loop
+        run: |
+          for i in {1..5}; do
+            echo "=== Burn-in iteration $i/5 ==="
+            npx playwright test --grep-invert "@skip" || exit 1
+          done
+
+      - name: Upload burn-in results
+        if: failure()
+        uses: actions/upload-artifact@v4
+        with:
+          name: burn-in-failures
+          path: test-results/
+
+  # Selective testing (changed files only)
+  selective:
+    name: Selective Tests
+    runs-on: ubuntu-latest
+    if: github.event_name == 'pull_request'
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0  # Full history for git diff
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version-file: '.nvmrc'
+          cache: 'npm'
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Install Playwright browsers
+        run: npx playwright install --with-deps
+
+      - name: Run selective tests
+        run: npm run test:changed
+```
+
+#### GitLab CI (`.gitlab-ci.yml`):
+
+```yaml
+variables:
+  NODE_VERSION: "18"
+
+stages:
+  - test
+  - burn-in
+
+# Test job with parallel execution
+test:
+  stage: test
+  image: node:$NODE_VERSION
+  parallel: 4
+  script:
+    - npm ci
+    - npx playwright install --with-deps
+    - npx playwright test --shard=$CI_NODE_INDEX/$CI_NODE_TOTAL
+  artifacts:
+    when: always
+    paths:
+      - test-results/
+      - playwright-report/
+    expire_in: 7 days
+  rules:
+    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
+    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
+
+# Burn-in job for flakiness detection
+burn-in:
+  stage: burn-in
+  image: node:$NODE_VERSION
+  script:
+    - npm ci
+    - npx playwright install --with-deps
+    - |
+      for i in {1..5}; do
+        echo "=== Burn-in iteration $i/5 ==="
+        npx playwright test || exit 1
+      done
+  artifacts:
+    when: on_failure
+    paths:
+      - test-results/
+  rules:
+    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
+```
+
+#### Burn-In Testing
+
+**Option 1: Classic Burn-In (Playwright Built-In)**
+
+```json
+{
+  "scripts": {
+    "test": "playwright test",
+    "test:burn-in": "playwright test --repeat-each=5 --retries=0"
+  }
+}
+```
+
+**How it works:**
+- Runs every test 5 times
+- Fails if any iteration fails
+- Detects flakiness before merge
+
+**Use when:** Small test suite, want to run everything multiple times
+
+---
+
+**Option 2: Smart Burn-In (Playwright Utils)**
+
+If `tea_use_playwright_utils: true`:
+
+**scripts/burn-in-changed.ts:**
+```typescript
+import { runBurnIn } from '@seontechnologies/playwright-utils/burn-in';
+
+await runBurnIn({
+  configPath: 'playwright.burn-in.config.ts',
+  baseBranch: 'main'
+});
+```
+
+**playwright.burn-in.config.ts:**
+```typescript
+import type { BurnInConfig } from '@seontechnologies/playwright-utils/burn-in';
+
+const config: BurnInConfig = {
+  skipBurnInPatterns: ['**/config/**', '**/*.md', '**/*types*'],
+  burnInTestPercentage: 0.3,
+  burnIn: { repeatEach: 5, retries: 0 }
+};
+
+export default config;
+```
+
+**package.json:**
+```json
+{
+  "scripts": {
+    "test:burn-in": "tsx scripts/burn-in-changed.ts"
+  }
+}
+```
+
+**How it works:**
+- Git diff analysis (only affected tests)
+- Smart filtering (skip configs, docs, types)
+- Volume control (run 30% of affected tests)
+- Each test runs 5 times
+
+**Use when:** Large test suite, want intelligent selection
+
+---
+
+**Comparison:**
+
+| Feature | Classic Burn-In | Smart Burn-In (PW-Utils) |
+|---------|----------------|--------------------------|
+| Changed 1 file | Runs all 500 tests × 5 = 2500 runs | Runs 3 affected tests × 5 = 15 runs |
+| Config change | Runs all tests | Skips (no tests affected) |
+| Type change | Runs all tests | Skips (no runtime impact) |
+| Setup | Zero config | Requires config file |
+
+**Recommendation:** Start with classic (simple), upgrade to smart (faster) when suite grows.
+
+### 6. Configure Secrets
+
+TEA provides a secrets checklist.
+
+**Required Secrets** (add to CI/CD platform):
+
+```markdown
+## GitHub Actions Secrets
+
+Repository Settings → Secrets and variables → Actions
+
+### Required
+- None (tests run without external auth)
+
+### Optional
+- `TEST_USER_EMAIL` - Test user credentials
+- `TEST_USER_PASSWORD` - Test user password
+- `API_BASE_URL` - API endpoint for tests
+- `DATABASE_URL` - Test database (if needed)
+```
+
+**How to Add Secrets:**
+
+**GitHub Actions:**
+1. Go to repo Settings → Secrets → Actions
+2. Click "New repository secret"
+3. Add name and value
+4. Use in workflow: `${{ secrets.TEST_USER_EMAIL }}`
+
+**GitLab CI:**
+1. Go to Project Settings → CI/CD → Variables
+2. Add variable name and value
+3. Use in workflow: `$TEST_USER_EMAIL`
+
+### 7. Test the CI Pipeline
+
+#### Push and Verify
+
+**Commit the workflow file:**
+```bash
+git add .github/workflows/test.yml
+git commit -m "ci: add automated test pipeline"
+git push
+```
+
+**Watch the CI run:**
+- GitHub Actions: Go to Actions tab
+- GitLab CI: Go to CI/CD → Pipelines
+- Circle CI: Go to Pipelines
+
+**Expected Result:**
+```
+✓ test (shard 1/4) - 3m 24s
+✓ test (shard 2/4) - 3m 18s
+✓ test (shard 3/4) - 3m 31s
+✓ test (shard 4/4) - 3m 15s
+✓ burn-in - 15m 42s
+```
+
+#### Test on Pull Request
+
+**Create test PR:**
+```bash
+git checkout -b test-ci-setup
+echo "# Test" > test.md
+git add test.md
+git commit -m "test: verify CI setup"
+git push -u origin test-ci-setup
+```
+
+**Open PR and verify:**
+- Tests run automatically
+- Burn-in runs (if configured for PRs)
+- Selective tests run (if applicable)
+- All checks pass ✓
+
+## What You Get
+
+### Automated Test Execution
+- **On every PR** - Catch issues before merge
+- **On every push to main** - Protect production
+- **Nightly** - Comprehensive regression testing
+
+### Parallel Execution
+- **4x faster feedback** - Shard across multiple workers
+- **Efficient resource usage** - Maximize CI runner utilization
+
+### Selective Testing
+- **Run only affected tests** - Git diff-based selection
+- **Faster PR feedback** - Don't run entire suite every time
+
+### Flakiness Detection
+- **Burn-in loops** - Run tests multiple times
+- **Early detection** - Catch flaky tests in PRs
+- **Confidence building** - Know tests are reliable
+
+### Artifact Collection
+- **Test results** - Saved for 7 days
+- **Screenshots** - On test failures
+- **Videos** - Full test recordings
+- **Traces** - Playwright trace files for debugging
+
+## Tips
+
+### Start Simple, Add Complexity
+
+**Week 1:** Basic pipeline
+```yaml
+- Run tests on PR
+- Single worker (no sharding)
+```
+
+**Week 2:** Add parallelization
+```yaml
+- Shard across 4 workers
+- Faster feedback
+```
+
+**Week 3:** Add selective testing
+```yaml
+- Git diff-based selection
+- Skip unaffected tests
+```
+
+**Week 4:** Add burn-in
+```yaml
+- Detect flaky tests
+- Run on PR and nightly
+```
+
+### Optimize for Feedback Speed
+
+**Goal:** PR feedback in < 5 minutes
+
+**Strategies:**
+- Shard tests across workers (4 workers = 4x faster)
+- Use selective testing (run 20% of tests, not 100%)
+- Cache dependencies (`actions/cache`, `cache: 'npm'`)
+- Run smoke tests first, full suite after
+
+**Example fast workflow:**
+```yaml
+jobs:
+  smoke:
+    # Run critical path tests (2 min)
+    run: npm run test:smoke
+
+  full:
+    needs: smoke
+    # Run full suite only if smoke passes (10 min)
+    run: npm test
+```
+
+### Use Test Tags
+
+Tag tests for selective execution:
+
+```typescript
+// Critical path tests (always run)
+test('@critical should login', async ({ page }) => { });
+
+// Smoke tests (run first)
+test('@smoke should load homepage', async ({ page }) => { });
+
+// Slow tests (run nightly only)
+test('@slow should process large file', async ({ page }) => { });
+
+// Skip in CI
+test('@local-only should use local service', async ({ page }) => { });
+```
+
+**In CI:**
+```bash
+# PR: Run critical and smoke only
+npx playwright test --grep "@critical|@smoke"
+
+# Nightly: Run everything except local-only
+npx playwright test --grep-invert "@local-only"
+```
+
+### Monitor CI Performance
+
+Track metrics:
+
+```markdown
+## CI Metrics
+
+| Metric | Target | Current | Status |
+|--------|--------|---------|--------|
+| PR feedback time | < 5 min | 3m 24s | ✅ |
+| Full suite time | < 15 min | 12m 18s | ✅ |
+| Flakiness rate | < 1% | 0.3% | ✅ |
+| CI cost/month | < $100 | $75 | ✅ |
+```
+
+### Handle Flaky Tests
+
+When burn-in detects flakiness:
+
+1. **Quarantine flaky test:**
+```typescript
+test.skip('flaky test - investigating', async ({ page }) => {
+  // TODO: Fix flakiness
+});
+```
+
+2. **Investigate with trace viewer:**
+```bash
+npx playwright show-trace test-results/trace.zip
+```
+
+3. **Fix root cause:**
+- Add network-first patterns
+- Remove hard waits
+- Fix race conditions
+
+4. **Verify fix:**
+```bash
+npm run test:burn-in -- tests/flaky.spec.ts --repeat 20
+```
+
+### Secure Secrets
+
+**Don't commit secrets to code:**
+```yaml
+# ❌ Bad
+- run: API_KEY=sk-1234... npm test
+
+# ✅ Good
+- run: npm test
+  env:
+    API_KEY: ${{ secrets.API_KEY }}
+```
+
+**Use environment-specific secrets:**
+- `STAGING_API_URL`
+- `PROD_API_URL`
+- `TEST_API_URL`
+
+### Cache Aggressively
+
+Speed up CI with caching:
+
+```yaml
+# Cache node_modules
+- uses: actions/setup-node@v4
+  with:
+    cache: 'npm'
+
+# Cache Playwright browsers
+- name: Cache Playwright browsers
+  uses: actions/cache@v4
+  with:
+    path: ~/.cache/ms-playwright
+    key: playwright-${{ hashFiles('package-lock.json') }}
+```
+
+## Common Issues
+
+### Tests Pass Locally, Fail in CI
+
+**Symptoms:**
+- Green locally, red in CI
+- "Works on my machine"
+
+**Common Causes:**
+- Different Node version
+- Different browser version
+- Missing environment variables
+- Timezone differences
+- Race conditions (CI slower)
+
+**Solutions:**
+```yaml
+# Pin Node version
+- uses: actions/setup-node@v4
+  with:
+    node-version-file: '.nvmrc'
+
+# Pin browser versions
+- run: npx playwright install --with-deps chromium@1.40.0
+
+# Set timezone
+  env:
+    TZ: 'America/New_York'
+```
+
+### CI Takes Too Long
+
+**Problem:** CI takes 30+ minutes, developers wait too long.
+
+**Solutions:**
+1. **Shard tests:** 4 workers = 4x faster
+2. **Selective testing:** Only run affected tests on PR
+3. **Smoke tests first:** Run critical path (2 min), full suite after
+4. **Cache dependencies:** `npm ci` with cache
+5. **Optimize tests:** Remove slow tests, hard waits
+
+### Burn-In Always Fails
+
+**Problem:** Burn-in job fails every time.
+
+**Cause:** Test suite is flaky.
+
+**Solution:**
+1. Identify flaky tests (check which iteration fails)
+2. Fix flaky tests using `*test-review`
+3. Re-run burn-in on specific files:
+```bash
+npm run test:burn-in tests/flaky.spec.ts
+```
+
+### Out of CI Minutes
+
+**Problem:** Using too many CI minutes, hitting plan limit.
+
+**Solutions:**
+1. Run full suite only on main branch
+2. Use selective testing on PRs
+3. Run expensive tests nightly only
+4. Self-host runners (for GitHub Actions)
+
+## Related Guides
+
+- [How to Set Up Test Framework](/docs/how-to/workflows/setup-test-framework.md) - Run first
+- [How to Run Test Review](/docs/how-to/workflows/run-test-review.md) - Audit CI tests
+- [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) - Burn-in utility
+
+## Understanding the Concepts
+
+- [Test Quality Standards](/docs/explanation/tea/test-quality-standards.md) - Why determinism matters
+- [Network-First Patterns](/docs/explanation/tea/network-first-patterns.md) - Avoid CI flakiness
+
+## Reference
+
+- [Command: *ci](/docs/reference/tea/commands.md#ci) - Full command reference
+- [TEA Configuration](/docs/reference/tea/configuration.md) - CI-related config options
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/how-to/workflows/setup-party-mode.md

@@ -3,11 +3,8 @@ title: "How to Set Up Party Mode"
 description: How to set up and use Party Mode for multi-agent collaboration
 ---
 
-
 Use Party Mode to orchestrate dynamic multi-agent conversations with your entire BMad team.
 
----
-
 ## When to Use This
 
 - Exploring complex topics that benefit from diverse expert perspectives
@@ -15,14 +12,10 @@ Use Party Mode to orchestrate dynamic multi-agent conversations with your entire
 - Getting comprehensive views across multiple domains
 - Strategic decisions with trade-offs
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed with multiple agents
 - Any agent loaded that supports party mode
-
----
+:::
 
 ## Steps
 
@@ -62,56 +55,35 @@ The facilitator will:
 
 Type "exit" or "done" to conclude the session. Participating agents will say personalized farewells.
 
----
-
 ## What Happens
 
-1. **Agent Roster** - Party Mode loads your complete agent roster
-2. **Introduction** - Available team members are introduced
-3. **Topic Analysis** - The facilitator analyzes your topic
-4. **Agent Selection** - 2-3 most relevant agents are selected
-5. **Discussion** - Agents respond, reference each other, engage in cross-talk
-6. **Exit** - Session concludes with farewells
-
----
+1. **Agent Roster** — Party Mode loads your complete agent roster
+2. **Introduction** — Available team members are introduced
+3. **Topic Analysis** — The facilitator analyzes your topic
+4. **Agent Selection** — 2-3 most relevant agents are selected
+5. **Discussion** — Agents respond, reference each other, engage in cross-talk
+6. **Exit** — Session concludes with farewells
 
 ## Example Party Compositions
 
-### Product Strategy
-- PM + Innovation Strategist (CIS) + Analyst
-
-### Technical Design
-- Architect + Creative Problem Solver (CIS) + Game Architect
-
-### User Experience
-- UX Designer + Design Thinking Coach (CIS) + Storyteller (CIS)
-
-### Quality Assessment
-- TEA + DEV + Architect
-
----
+| Topic                  | Typical Agents                                        |
+| ---------------------- | ----------------------------------------------------- |
+| **Product Strategy**   | PM + Innovation Strategist + Analyst                  |
+| **Technical Design**   | Architect + Creative Problem Solver  + Game Architect |
+| **User Experience**    | UX Designer + Design Thinking Coach  + Storyteller    |
+| **Quality Assessment** | TEA + DEV + Architect                                 |
 
 ## Key Features
 
-- **Intelligent agent selection** - Selects based on expertise needed
-- **Authentic personalities** - Each agent maintains their unique voice
-- **Natural cross-talk** - Agents reference and build on each other
-- **Optional TTS** - Voice configurations for each agent
-- **Graceful exit** - Personalized farewells
-
----
+- **Intelligent agent selection** — Selects based on expertise needed
+- **Authentic personalities** — Each agent maintains their unique voice
+- **Natural cross-talk** — Agents reference and build on each other
+- **Graceful exit** — Personalized farewells
 
 ## Tips
 
-- Be specific about your topic for better agent selection
-- Let the conversation flow naturally
-- Ask follow-up questions to go deeper
-- Take notes on key insights
-- Use for strategic decisions, not routine tasks
-
----
-
-## Related
-
-- [Party Mode](/docs/explanation/features/party-mode.md) - Understanding Party Mode
-- [Agent Roles](/docs/explanation/core-concepts/agent-roles.md) - Available agents
+- **Be specific about your topic** — Better agent selection
+- **Let the conversation flow** — Don't over-direct
+- **Ask follow-up questions** — Go deeper on interesting points
+- **Take notes on key insights** — Capture valuable perspectives
+- **Use for strategic decisions** — Not routine tasks

docs/how-to/workflows/setup-test-framework.md

@@ -1,13 +1,10 @@
 ---
-title: "How to Set Up a Test Framework"
+title: "How to Set Up a Test Framework with TEA"
 description: How to set up a production-ready test framework using TEA
 ---
 
-
 Use TEA's `*framework` workflow to scaffold a production-ready test framework for your project.
 
----
-
 ## When to Use This
 
 - No existing test framework in your project
@@ -15,15 +12,11 @@ Use TEA's `*framework` workflow to scaffold a production-ready test framework fo
 - Starting a new project that needs testing infrastructure
 - Phase 3 (Solutioning) after architecture is complete
 
----
-
-## Prerequisites
-
+:::note[Prerequisites]
 - BMad Method installed
 - Architecture completed (or at least tech stack decided)
 - TEA agent available
-
----
+:::
 
 ## Steps
 
@@ -50,13 +43,11 @@ TEA will ask about:
 
 TEA generates:
 
-- **Test scaffold** - Directory structure and config files
-- **Sample specs** - Example tests following best practices
-- **`.env.example`** - Environment variable template
-- **`.nvmrc`** - Node version specification
-- **README updates** - Testing documentation
-
----
+- **Test scaffold** — Directory structure and config files
+- **Sample specs** — Example tests following best practices
+- **`.env.example`** — Environment variable template
+- **`.nvmrc`** — Node version specification
+- **README updates** — Testing documentation
 
 ## What You Get
 
@@ -71,8 +62,6 @@ tests/
 └── README.md
 ```
 
----
-
 ## Optional: Playwright Utils Integration
 
 TEA can integrate with `@seontechnologies/playwright-utils` for advanced fixtures:
@@ -85,29 +74,25 @@ Enable during BMad installation or set `tea_use_playwright_utils: true` in confi
 
 **Utilities available:** api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor
 
----
-
 ## Optional: MCP Enhancements
 
 TEA can use Playwright MCP servers for enhanced capabilities:
 
-- `playwright` - Browser automation
-- `playwright-test` - Test runner with failure analysis
+- `playwright` — Browser automation
+- `playwright-test` — Test runner with failure analysis
 
 Configure in your IDE's MCP settings.
 
----
-
 ## Tips
 
-- Run `*framework` only once per repository
-- Run after architecture is complete so framework aligns with tech stack
-- Follow up with `*ci` to set up CI/CD pipeline
+- **Run only once per repository** — Framework setup is a one-time operation
+- **Run after architecture is complete** — Framework aligns with tech stack
+- **Follow up with CI setup** — Run `*ci` to configure CI/CD pipeline
 
----
+## Next Steps
 
-## Related
+After test framework setup:
 
-- [TEA Overview](/docs/explanation/features/tea-overview.md) - Understanding the Test Architect
-- [Run Test Design](/docs/how-to/workflows/run-test-design.md) - Creating test plans
-- [Create Architecture](/docs/how-to/workflows/create-architecture.md) - Architecture workflow
+1. **Test Design** — Create test plans for system or epics
+2. **CI Configuration** — Set up automated test runs
+3. **Story Implementation** — Tests are ready for development

docs/reference/agents/index.md

@@ -3,139 +3,107 @@ title: "Agents Reference"
 description: Complete reference for BMad Method agents and their commands
 ---
 
-
 Quick reference of all BMad Method agents and their available commands.
 
----
+:::tip[Universal Commands]
+All agents support: `*menu` (redisplay options), `*dismiss` (dismiss agent), and `*party-mode` (multi-agent collaboration).
+:::
 
 ## Analyst (Mary)
 
 Business analysis and research.
 
 **Commands:**
-- `*workflow-status` - Get workflow status or initialize tracking
-- `*brainstorm-project` - Guided brainstorming session
-- `*research` - Market, domain, competitive, or technical research
-- `*product-brief` - Create a product brief (input for PRD)
-- `*document-project` - Document existing brownfield projects
-
----
+- `*workflow-status` — Get workflow status or initialize tracking
+- `*brainstorm-project` — Guided brainstorming session
+- `*research` — Market, domain, competitive, or technical research
+- `*product-brief` — Create a product brief (input for PRD)
+- `*document-project` — Document existing brownfield projects
 
 ## PM (John)
 
 Product requirements and planning.
 
 **Commands:**
-- `*workflow-status` - Get workflow status or initialize tracking
-- `*create-prd` - Create Product Requirements Document
-- `*create-epics-and-stories` - Break PRD into epics and user stories (after Architecture)
-- `*implementation-readiness` - Validate PRD, UX, Architecture, Epics alignment
-- `*correct-course` - Course correction during implementation
-
----
+- `*workflow-status` — Get workflow status or initialize tracking
+- `*create-prd` — Create Product Requirements Document
+- `*create-epics-and-stories` — Break PRD into epics and user stories (after Architecture)
+- `*implementation-readiness` — Validate PRD, UX, Architecture, Epics alignment
+- `*correct-course` — Course correction during implementation
 
 ## Architect (Winston)
 
 System architecture and technical design.
 
 **Commands:**
-- `*workflow-status` - Get workflow status or initialize tracking
-- `*create-architecture` - Create architecture document to guide development
-- `*implementation-readiness` - Validate PRD, UX, Architecture, Epics alignment
-- `*create-excalidraw-diagram` - System architecture or technical diagrams
-- `*create-excalidraw-dataflow` - Data flow diagrams
-
----
+- `*workflow-status` — Get workflow status or initialize tracking
+- `*create-architecture` — Create architecture document to guide development
+- `*implementation-readiness` — Validate PRD, UX, Architecture, Epics alignment
+- `*create-excalidraw-diagram` — System architecture or technical diagrams
+- `*create-excalidraw-dataflow` — Data flow diagrams
 
 ## SM (Bob)
 
 Sprint planning and story preparation.
 
 **Commands:**
-- `*sprint-planning` - Generate sprint-status.yaml from epic files
-- `*create-story` - Create story from epic (prep for development)
-- `*validate-create-story` - Validate story quality
-- `*epic-retrospective` - Team retrospective after epic completion
-- `*correct-course` - Course correction during implementation
-
----
+- `*sprint-planning` — Generate sprint-status.yaml from epic files
+- `*create-story` — Create story from epic (prep for development)
+- `*validate-create-story` — Validate story quality
+- `*epic-retrospective` — Team retrospective after epic completion
+- `*correct-course` — Course correction during implementation
 
 ## DEV (Amelia)
 
 Story implementation and code review.
 
 **Commands:**
-- `*dev-story` - Execute story workflow (implementation with tests)
-- `*code-review` - Thorough code review
-
----
+- `*dev-story` — Execute story workflow (implementation with tests)
+- `*code-review` — Thorough code review
 
 ## Quick Flow Solo Dev (Barry)
 
 Fast solo development without handoffs.
 
 **Commands:**
-- `*quick-spec` - Architect technical spec with implementation-ready stories
-- `*quick-dev` - Implement tech spec end-to-end solo
-- `*code-review` - Review and improve code
-
----
+- `*quick-spec` — Architect technical spec with implementation-ready stories
+- `*quick-dev` — Implement tech spec end-to-end solo
+- `*code-review` — Review and improve code
 
 ## TEA (Murat)
 
 Test architecture and quality strategy.
 
 **Commands:**
-- `*framework` - Initialize production-ready test framework
-- `*atdd` - Generate E2E tests first (before implementation)
-- `*automate` - Comprehensive test automation
-- `*test-design` - Create comprehensive test scenarios
-- `*trace` - Map requirements to tests, quality gate decision
-- `*nfr-assess` - Validate non-functional requirements
-- `*ci` - Scaffold CI/CD quality pipeline
-- `*test-review` - Review test quality
-
----
+- `*framework` — Initialize production-ready test framework
+- `*atdd` — Generate E2E tests first (before implementation)
+- `*automate` — Comprehensive test automation
+- `*test-design` — Create comprehensive test scenarios
+- `*trace` — Map requirements to tests, quality gate decision
+- `*nfr-assess` — Validate non-functional requirements
+- `*ci` — Scaffold CI/CD quality pipeline
+- `*test-review` — Review test quality
 
 ## UX Designer (Sally)
 
 User experience and UI design.
 
 **Commands:**
-- `*create-ux-design` - Generate UX design and UI plan from PRD
-- `*validate-design` - Validate UX specification and design artifacts
-- `*create-excalidraw-wireframe` - Create website or app wireframe
-
----
+- `*create-ux-design` — Generate UX design and UI plan from PRD
+- `*validate-design` — Validate UX specification and design artifacts
+- `*create-excalidraw-wireframe` — Create website or app wireframe
 
 ## Technical Writer (Paige)
 
 Technical documentation and diagrams.
 
 **Commands:**
-- `*document-project` - Comprehensive project documentation
-- `*generate-mermaid` - Generate Mermaid diagrams
-- `*create-excalidraw-flowchart` - Process and logic flow visualizations
-- `*create-excalidraw-diagram` - System architecture or technical diagrams
-- `*create-excalidraw-dataflow` - Data flow visualizations
-- `*validate-doc` - Review documentation against standards
-- `*improve-readme` - Review and improve README files
-- `*explain-concept` - Create clear technical explanations
-- `*standards-guide` - Show BMad documentation standards
-
----
-
-## Universal Commands
-
-Available to all agents:
-
-- `*menu` - Redisplay menu options
-- `*dismiss` - Dismiss agent
-- `*party-mode` - Multi-agent collaboration (most agents)
-
----
-
-## Related
-
-- [Agent Roles](/docs/explanation/core-concepts/agent-roles.md) - Understanding agent responsibilities
-- [What Are Agents](/docs/explanation/core-concepts/what-are-agents.md) - Foundational concepts
+- `*document-project` — Comprehensive project documentation
+- `*generate-mermaid` — Generate Mermaid diagrams
+- `*create-excalidraw-flowchart` — Process and logic flow visualizations
+- `*create-excalidraw-diagram` — System architecture or technical diagrams
+- `*create-excalidraw-dataflow` — Data flow visualizations
+- `*validate-doc` — Review documentation against standards
+- `*improve-readme` — Review and improve README files
+- `*explain-concept` — Create clear technical explanations
+- `*standards-guide` — Show BMad documentation standards

docs/reference/configuration/core-tasks.md

@@ -2,66 +2,66 @@
 title: "Core Tasks"
 ---
 
+Reusable task definitions that can be invoked by any BMad module, workflow, or agent.
 
-Core Tasks are reusable task definitions that can be invoked by any BMad module, workflow, or agent. These tasks provide standardized functionality for common operations.
-
-## Table of Contents
+## Contents
 
 - [Index Docs](#index-docs) — Generate directory index files
-- [Adversarial Review](#adversarial-review-general) — Critical content review
+- [Adversarial Review](#adversarial-review) — Critical content review
 - [Shard Document](#shard-document) — Split large documents into sections
 
----
-
 ## Index Docs
 
-**Generates or updates an index.md file documenting all documents in a specified directory.**
+**Generates or updates an index.md file documenting all files in a specified directory.**
 
-This task scans a target directory, reads file contents to understand their purpose, and creates a well-organized index with accurate descriptions. Files are grouped by type, purpose, or subdirectory, and descriptions are generated from actual content rather than guessing from filenames.
-
-**Use it when:** You need to create navigable documentation for a folder of markdown files, or you want to maintain an updated index as content evolves.
+**Use it when:**
+- You need navigable documentation for a folder of markdown files
+- You want to maintain an updated index as content evolves
 
 **How it works:**
 1. Scan the target directory for files and subdirectories
 2. Group content by type, purpose, or location
-3. Read each file to generate brief (3-10 word) descriptions based on actual content
-4. Create or update index.md with organized listings using relative paths
+3. Read each file to generate brief (3-10 word) descriptions
+4. Create or update index.md with organized listings
 
-**Output format:** A markdown index with sections for Files and Subdirectories, each entry containing a relative link and description.
+**Output:** Markdown index with sections for Files and Subdirectories, each entry containing a relative link and description.
 
----
-
-## Adversarial Review (General)
+## Adversarial Review
 
 **Performs a cynical, skeptical review of any content to identify issues and improvement opportunities.**
 
-This task applies adversarial thinking to content review—approaching the material with the assumption that problems exist. It's designed to find what's missing, not just what's wrong, and produces at least ten specific findings. The reviewer adopts a professional but skeptical tone, looking for gaps, inconsistencies, oversights, and areas that need clarification.
-
-**Use it when:** You need a critical eye on code diffs, specifications, user stories, documentation, or any artifact before finalizing. It's particularly valuable before merging code, releasing documentation, or considering a specification complete.
+**Use it when:**
+- Reviewing code diffs before merging
+- Finalizing specifications or user stories
+- Releasing documentation
+- Any artifact needs a critical eye before completion
 
 **How it works:**
-1. Load the content to review (diff, branch, uncommitted changes, document, etc.)
-2. Perform adversarial analysis with extreme skepticism—assume problems exist
+1. Load the content to review (diff, branch, document, etc.)
+2. Perform adversarial analysis — assume problems exist
 3. Find at least ten issues to fix or improve
 4. Output findings as a markdown list
 
-**Note:** This task is designed to run in a separate subagent/process with read access to the project but no prior context, ensuring an unbiased review.
-
----
+:::note[Unbiased Review]
+This task runs in a separate subagent with read access but no prior context, ensuring an unbiased review.
+:::
 
 ## Shard Document
 
-**Splits large markdown documents into smaller, organized files based on level 2 (##) sections.**
+**Splits large markdown documents into smaller files based on level 2 (`##`) sections.**
 
-Uses the `@kayvan/markdown-tree-parser` tool to automatically break down large documents into a folder structure. Each level 2 heading becomes a separate file, and an index.md is generated to tie everything together. This makes large documents more maintainable and allows for easier navigation and updates to individual sections.
-
-**Use it when:** A markdown file has grown too large to effectively work with, or you want to break a monolithic document into manageable sections that can be edited independently.
+**Use it when:**
+- A markdown file has grown too large to work with effectively
+- You want to break a monolithic document into manageable sections
+- Individual sections need to be edited independently
 
 **How it works:**
-1. Confirm source document path and verify it's a markdown file
-2. Determine destination folder (defaults to same location as source, folder named after document)
-3. Execute the sharding command using npx @kayvan/markdown-tree-parser
+1. Confirm source document path (must be markdown)
+2. Determine destination folder (defaults to folder named after document)
+3. Execute sharding via `npx @kayvan/markdown-tree-parser`
 4. Verify output files and index.md were created
-5. Handle the original document—delete, move to archive, or keep with warning
+5. Handle original document — delete, move to archive, or keep
 
-**Handling the original:** After sharding, the task prompts you to delete, archive, or keep the original document. Deleting or archiving is recommended to avoid confusion and ensure updates happen in the sharded files only.
+:::caution[Original File]
+After sharding, delete or archive the original to avoid confusion. Updates should happen in the sharded files only.
+:::

docs/reference/configuration/global-config.md

@@ -1,14 +1,28 @@
 ---
-title: "Core Module Global Inheritable Config"
+title: "Global Inheritable Config"
 ---
 
+Configuration values defined in the Core Module that all other modules inherit by default.
 
-The Core Modules module.yaml file defines configuration values that are useful and unique for all other modules to utilize, and by default all other modules installed will clone the values defined in the core module yaml.config into their own. It is possible for other modules to override these values, but the general intent it to accept the core module values and define their own values as needed, or extend the core values.
+## Core Config Values
 
-Currently, the core module.yaml config will define (asking the user upon installation, and recording to the core module config.yaml):
-- `user_name`: string (defaults to the system defined user name)
-- `communication_language`: string (defaults to english)
-- `document_output_language`: string (defaults to english)
-- `output_folder`: string (default `_bmad-output`)
+These values are set during installation and recorded to the core `module.yaml`:
 
-An example of extending one of these values, in the BMad Method module.yaml it defines a planning_artifacts config, which will default to `default: "{output_folder}/planning-artifacts"` thus whatever the output_folder will be, this extended versions default will use the value from this core module and append a new folder onto it. The user can choose to replace this without utilizing the output_folder from the core if they so chose.
+| Config Key | Default | Description |
+|------------|---------|-------------|
+| `user_name` | System username | User's display name |
+| `communication_language` | `english` | Language for agent communication |
+| `document_output_language` | `english` | Language for generated documents |
+| `output_folder` | `_bmad-output` | Directory for workflow outputs |
+
+## Inheritance Behavior
+
+All installed modules automatically clone these values into their own config. Modules can:
+
+- **Accept defaults** — Use core values as-is (recommended)
+- **Override values** — Replace with module-specific settings
+- **Extend values** — Build on core values with additional paths
+
+:::tip[Extending Config]
+Use `{output_folder}` to reference the core value. Example: BMad Method defines `planning_artifacts` as `{output_folder}/planning-artifacts`, automatically inheriting whatever output folder the user configured.
+:::

docs/reference/glossary/index.md

@@ -2,371 +2,158 @@
 title: "BMad Glossary"
 ---
 
-
-Comprehensive terminology reference for the BMad Method.
-
----
-
-## Navigation
-
-- [Core Concepts](#core-concepts)
-- [Scale and Complexity](#scale-and-complexity)
-- [Planning Documents](#planning-documents)
-- [Workflow and Phases](#workflow-and-phases)
-- [Agents and Roles](#agents-and-roles)
-- [Status and Tracking](#status-and-tracking)
-- [Project Types](#project-types)
-- [Implementation Terms](#implementation-terms)
-- [Game Development Terms](#game-development-terms)
-
----
+Terminology reference for the BMad Method.
 
 ## Core Concepts
 
-### BMad (Breakthrough Method of Agile AI Driven Development)
-
-AI-driven agile development framework with specialized agents, guided workflows, and scale-adaptive intelligence.
-
-### BMM (BMad Method Module)
-
-Core orchestration system for AI-driven agile development, providing comprehensive lifecycle management through specialized agents and workflows.
-
-### BMad Method
-
-The complete methodology for AI-assisted software development, encompassing planning, architecture, implementation, and quality assurance workflows that adapt to project complexity.
-
-### Scale-Adaptive System
-
-BMad Method's intelligent workflow orchestration that automatically adjusts planning depth, documentation requirements, and implementation processes based on project needs through three distinct planning tracks (Quick Flow, BMad Method, Enterprise Method).
-
-### Agent
-
-A specialized AI persona with specific expertise (PM, Architect, SM, DEV, TEA) that guides users through workflows and creates deliverables. Agents have defined capabilities, communication styles, and workflow access.
-
-### Workflow
-
-A multi-step guided process that orchestrates AI agent activities to produce specific deliverables. Workflows are interactive and adapt to user context.
-
----
+| Term                      | Definition                                                                                                                                                                        |
+| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Agent**                 | Specialized AI persona with specific expertise (PM, Architect, SM, DEV, TEA) that guides users through workflows and creates deliverables.                                        |
+| **BMad**                  | Breakthrough Method of Agile AI-Driven Development — AI-driven agile framework with specialized agents, guided workflows, and scale-adaptive intelligence.                        |
+| **BMad Method**           | Complete methodology for AI-assisted software development, encompassing planning, architecture, implementation, and quality assurance workflows that adapt to project complexity. |
+| **BMM**                   | BMad Method Module — core orchestration system providing comprehensive lifecycle management through specialized agents and workflows.                                             |
+| **Scale-Adaptive System** | Intelligent workflow orchestration that adjusts planning depth and documentation requirements based on project needs through three planning tracks.                               |
+| **Workflow**              | Multi-step guided process that orchestrates AI agent activities to produce specific deliverables. Workflows are interactive and adapt to user context.                            |
 
 ## Scale and Complexity
 
-### Quick Flow Track
-
-Fast implementation track using tech-spec planning only. Best for bug fixes, small features, and changes with clear scope. Typical range: 1-15 stories. No architecture phase needed. Examples: bug fixes, OAuth login, search features.
-
-### BMad Method Track
-
-Full product planning track using PRD + Architecture + UX. Best for products, platforms, and complex features requiring system design. Typical range: 10-50+ stories. Examples: admin dashboards, e-commerce platforms, SaaS products.
-
-### Enterprise Method Track
-
-Extended enterprise planning track adding Security Architecture, DevOps Strategy, and Test Strategy to BMad Method. Best for enterprise requirements, compliance needs, and multi-tenant systems. Typical range: 30+ stories. Examples: multi-tenant platforms, compliance-driven systems, mission-critical applications.
-
-### Planning Track
-
-The methodology path (Quick Flow, BMad Method, or Enterprise Method) chosen for a project based on planning needs, complexity, and requirements rather than story count alone.
-
-**Note:** Story counts are guidance, not definitions. Tracks are determined by what planning the project needs, not story math.
-
----
+| Term                        | Definition                                                                                                                                                                |
+| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **BMad Method Track**       | Full product planning track using PRD + Architecture + UX. Best for products, platforms, and complex features. Typical range: 10-50+ stories.                             |
+| **Enterprise Method Track** | Extended planning track adding Security Architecture, DevOps Strategy, and Test Strategy. Best for compliance needs and multi-tenant systems. Typical range: 30+ stories. |
+| **Planning Track**          | Methodology path (Quick Flow, BMad Method, or Enterprise) chosen based on planning needs and complexity, not story count alone.                                           |
+| **Quick Flow Track**        | Fast implementation track using tech-spec only. Best for bug fixes, small features, and clear-scope changes. Typical range: 1-15 stories.                                 |
 
 ## Planning Documents
 
-### Tech-Spec (Technical Specification)
-
-**Quick Flow track only.** Comprehensive technical plan created upfront that serves as the primary planning document for small changes or features. Contains problem statement, solution approach, file-level changes, stack detection (brownfield), testing strategy, and developer resources.
-
-### PRD (Product Requirements Document)
-
-**BMad Method/Enterprise tracks.** Product-level planning document containing vision, goals, Functional Requirements (FRs), Non-Functional Requirements (NFRs), success criteria, and UX considerations. Replaces tech-spec for larger projects that need product planning. **V6 Note:** PRD focuses on WHAT to build (requirements). Epic+Stories are created separately AFTER architecture via create-epics-and-stories workflow.
-
-### Architecture Document
-
-**BMad Method/Enterprise tracks.** System-wide design document defining structure, components, interactions, data models, integration patterns, security, performance, and deployment.
-
-**Scale-Adaptive:** Architecture complexity scales with track - BMad Method is lightweight to moderate, Enterprise Method is comprehensive with security/devops/test strategies.
-
-### Epics
-
-High-level feature groupings that contain multiple related stories. Typically span 5-15 stories each and represent cohesive functionality (e.g., "User Authentication Epic").
-
-### Product Brief
-
-Optional strategic planning document created in Phase 1 (Analysis) that captures product vision, market context, user needs, and high-level requirements before detailed planning.
-
-### GDD (Game Design Document)
-
-Game development equivalent of PRD, created by Game Designer agent for game projects. Comprehensive document detailing all aspects of game design: mechanics, systems, content, and more.
-
-### Game Brief
-
-Document capturing the game's core vision, pillars, target audience, and scope. Foundation for the GDD.
-
----
+| Term                      | Definition                                                                                                                                         |
+| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Architecture Document** | *BMad Method/Enterprise.* System-wide design document defining structure, components, data models, integration patterns, security, and deployment. |
+| **Epics**                 | High-level feature groupings containing multiple related stories. Typically 5-15 stories each representing cohesive functionality.                 |
+| **Game Brief**            | *BMGD.* Document capturing game's core vision, pillars, target audience, and scope. Foundation for the GDD.                                        |
+| **GDD**                   | *BMGD.* Game Design Document — comprehensive document detailing all aspects of game design: mechanics, systems, content, and more.                 |
+| **PRD**                   | *BMad Method/Enterprise.* Product Requirements Document containing vision, goals, FRs, NFRs, and success criteria. Focuses on WHAT to build.       |
+| **Product Brief**         | *Phase 1.* Optional strategic document capturing product vision, market context, and high-level requirements before detailed planning.             |
+| **Tech-Spec**             | *Quick Flow only.* Comprehensive technical plan with problem statement, solution approach, file-level changes, and testing strategy.               |
 
 ## Workflow and Phases
 
-### Phase 0: Documentation (Prerequisite)
-
-**Conditional phase for brownfield projects.** Creates comprehensive codebase documentation before planning. Only required if existing documentation is insufficient for AI agents.
-
-### Phase 1: Analysis (Optional)
-
-Discovery and research phase including brainstorming, research workflows, and product brief creation. Optional for Quick Flow, recommended for BMad Method, required for Enterprise Method.
-
-### Phase 2: Planning (Required)
-
-**Always required.** Creates formal requirements and work breakdown. Routes to tech-spec (Quick Flow) or PRD (BMad Method/Enterprise) based on selected track.
-
-### Phase 3: Solutioning (Track-Dependent)
-
-Architecture design phase. Required for BMad Method and Enterprise Method tracks. Includes architecture creation, validation, and gate checks.
-
-### Phase 4: Implementation (Required)
-
-Sprint-based development through story-by-story iteration. Uses sprint-planning, create-story, dev-story, code-review, and retrospective workflows.
-
-### Quick Spec Flow
-
-Fast-track workflow system for Quick Flow track projects that goes straight from idea to tech-spec to implementation, bypassing heavy planning. Designed for bug fixes, small features, and rapid prototyping.
-
----
+| Term                        | Definition                                                                                                                                     |
+| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Phase 0: Documentation**  | *Brownfield.* Conditional prerequisite phase creating codebase documentation before planning. Only required if existing docs are insufficient. |
+| **Phase 1: Analysis**       | Discovery phase including brainstorming, research, and product brief creation. Optional for Quick Flow, recommended for BMad Method.           |
+| **Phase 2: Planning**       | Required phase creating formal requirements. Routes to tech-spec (Quick Flow) or PRD (BMad Method/Enterprise).                                 |
+| **Phase 3: Solutioning**    | *BMad Method/Enterprise.* Architecture design phase including creation, validation, and gate checks.                                           |
+| **Phase 4: Implementation** | Required sprint-based development through story-by-story iteration using sprint-planning, create-story, dev-story, and code-review workflows.  |
+| **Quick Spec Flow**         | Fast-track workflow for Quick Flow projects going straight from idea to tech-spec to implementation.                                           |
+| **Workflow Init**           | Initialization workflow creating bmm-workflow-status.yaml, detecting project type, and determining planning track.                             |
+| **Workflow Status**         | Universal entry point checking for existing status file, displaying progress, and recommending next action.                                    |
 
 ## Agents and Roles
 
-### PM (Product Manager)
-
-Agent responsible for creating PRDs, tech-specs, and managing product requirements. Primary agent for Phase 2 planning.
-
-### Analyst (Business Analyst)
-
-Agent that initializes workflows, conducts research, creates product briefs, and tracks progress. Often the entry point for new projects.
-
-### Architect
-
-Agent that designs system architecture, creates architecture documents, performs technical reviews, and validates designs. Primary agent for Phase 3 solutioning.
-
-### SM (Scrum Master)
-
-Agent that manages sprints, creates stories, generates contexts, and coordinates implementation. Primary orchestrator for Phase 4 implementation.
-
-### DEV (Developer)
-
-Agent that implements stories, writes code, runs tests, and performs code reviews. Primary implementer in Phase 4.
-
-### TEA (Test Architect)
-
-Agent responsible for test strategy, quality gates, NFR assessment, and comprehensive quality assurance. Integrates throughout all phases.
-
-### Technical Writer
-
-Agent specialized in creating and maintaining high-quality technical documentation. Expert in documentation standards, information architecture, and professional technical writing.
-
-### UX Designer
-
-Agent that creates UX design documents, interaction patterns, and visual specifications for UI-heavy projects.
-
-### Game Designer
-
-Specialized agent for game development projects. Creates game design documents (GDD) and game-specific workflows.
-
-### Game Architect
-
-Agent that designs game system architecture, creates technical architecture for games, and validates game-specific designs.
-
-### BMad Master
-
-Meta-level orchestrator agent from BMad Core. Facilitates party mode, lists available tasks and workflows, and provides high-level guidance across all modules.
-
-### Party Mode
-
-Multi-agent collaboration feature where all installed agents discuss challenges together in real-time. BMad Master orchestrates, selecting 2-3 relevant agents per message for natural cross-talk and debate. Best for strategic decisions, creative brainstorming, cross-functional alignment, and complex problem-solving.
-
----
+| Term                 | Definition                                                                                                                                       |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Analyst**          | Agent that initializes workflows, conducts research, creates product briefs, and tracks progress. Often the entry point for new projects.        |
+| **Architect**        | Agent designing system architecture, creating architecture documents, and validating designs. Primary agent for Phase 3.                         |
+| **BMad Master**      | Meta-level orchestrator from BMad Core facilitating party mode and providing high-level guidance across all modules.                             |
+| **DEV**              | Developer agent implementing stories, writing code, running tests, and performing code reviews. Primary implementer in Phase 4.                  |
+| **Game Architect**   | *BMGD.* Agent designing game system architecture and validating game-specific technical designs.                                                 |
+| **Game Designer**    | *BMGD.* Agent creating game design documents (GDD) and running game-specific workflows.                                                          |
+| **Party Mode**       | Multi-agent collaboration feature where agents discuss challenges together. BMad Master orchestrates, selecting 2-3 relevant agents per message. |
+| **PM**               | Product Manager agent creating PRDs and tech-specs. Primary agent for Phase 2 planning.                                                          |
+| **SM**               | Scrum Master agent managing sprints, creating stories, and coordinating implementation. Primary orchestrator for Phase 4.                        |
+| **TEA**              | Test Architect agent responsible for test strategy, quality gates, and NFR assessment. Integrates throughout all phases.                         |
+| **Technical Writer** | Agent specialized in creating technical documentation, diagrams, and maintaining documentation standards.                                        |
+| **UX Designer**      | Agent creating UX design documents, interaction patterns, and visual specifications for UI-heavy projects.                                       |
 
 ## Status and Tracking
 
-### bmm-workflow-status.yaml
-
-**Phases 1-3.** Tracking file that shows current phase, completed workflows, progress, and next recommended actions. Created by workflow-init, updated automatically.
-
-### sprint-status.yaml
-
-**Phase 4 only.** Single source of truth for implementation tracking. Contains all epics, stories, and retrospectives with current status for each. Created by sprint-planning, updated by agents.
-
-### Story Status Progression
-
-```
-backlog → ready-for-dev → in-progress → review → done
-```
-
-- **backlog** - Story exists in epic but not yet created
-- **ready-for-dev** - Story file created via create-story; validation is optional
-- **in-progress** - DEV is implementing via dev-story
-- **review** - Implementation complete, awaiting code-review
-- **done** - Completed with DoD met
-
-### Epic Status Progression
-
-```
-backlog → in-progress → done
-```
-
-- **backlog** - Epic not yet started
-- **in-progress** - Epic actively being worked on
-- **done** - All stories in epic completed
-
-### Retrospective
-
-Workflow run after completing each epic to capture learnings, identify improvements, and feed insights into next epic planning. Critical for continuous improvement.
-
----
+| Term                         | Definition                                                                                                                   |
+| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
+| **bmm-workflow-status.yaml** | *Phases 1-3.* Tracking file showing current phase, completed workflows, and next recommended actions.                        |
+| **DoD**                      | Definition of Done — criteria for marking a story complete: implementation done, tests passing, code reviewed, docs updated. |
+| **Epic Status Progression**  | `backlog → in-progress → done` — lifecycle states for epics during implementation.                                           |
+| **Gate Check**               | Validation workflow (implementation-readiness) ensuring PRD, Architecture, and Epics are aligned before Phase 4.             |
+| **Retrospective**            | Workflow after each epic capturing learnings and improvements for continuous improvement.                                    |
+| **sprint-status.yaml**       | *Phase 4.* Single source of truth for implementation tracking containing all epics, stories, and their statuses.             |
+| **Story Status Progression** | `backlog → ready-for-dev → in-progress → review → done` — lifecycle states for stories.                                      |
 
 ## Project Types
 
-### Greenfield
-
-New project starting from scratch with no existing codebase. Freedom to establish patterns, choose stack, and design from clean slate.
-
-### Brownfield
-
-Existing project with established codebase, patterns, and constraints. Requires understanding existing architecture, respecting established conventions, and planning integration with current systems.
-
-**Critical:** Brownfield projects should run document-project workflow BEFORE planning to ensure AI agents have adequate context about existing code.
-
-### document-project Workflow
-
-**Brownfield prerequisite.** Analyzes and documents existing codebase, creating comprehensive documentation including project overview, architecture analysis, source tree, API contracts, and data models. Three scan levels: quick, deep, exhaustive.
-
----
+| Term                     | Definition                                                                                                                      |
+| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
+| **Brownfield**           | Existing project with established codebase and patterns. Requires understanding existing architecture and planning integration. |
+| **Convention Detection** | *Quick Flow.* Feature auto-detecting existing code style, naming conventions, and frameworks from brownfield codebases.         |
+| **document-project**     | *Brownfield.* Workflow analyzing and documenting existing codebase with three scan levels: quick, deep, exhaustive.             |
+| **Feature Flags**        | *Brownfield.* Implementation technique for gradual rollout, easy rollback, and A/B testing of new functionality.                |
+| **Greenfield**           | New project starting from scratch with freedom to establish patterns, choose stack, and design from clean slate.                |
+| **Integration Points**   | *Brownfield.* Specific locations where new code connects with existing systems. Must be documented in tech-specs.               |
 
 ## Implementation Terms
 
-### Story
-
-Single unit of implementable work with clear acceptance criteria, typically 2-8 hours of development effort. Stories are grouped into epics and tracked in sprint-status.yaml.
-
-### Story File
-
-Markdown file containing story details: description, acceptance criteria, technical notes, dependencies, implementation guidance, and testing requirements.
-
-### Story Context
-
-Implementation guidance embedded within story files during the create-story workflow. Provides implementation-specific context, references existing patterns, suggests approaches, and helps maintain consistency with established codebase conventions.
-
-### Sprint Planning
-
-Workflow that initializes Phase 4 implementation by creating sprint-status.yaml, extracting all epics/stories from planning docs, and setting up tracking infrastructure.
-
-### Sprint
-
-Time-boxed period of development work, typically 1-2 weeks.
-
-### Gate Check
-
-Validation workflow (implementation-readiness) run before Phase 4 to ensure PRD + Architecture + Epics + UX (optional) are aligned with no gaps or contradictions. Required for BMad Method and Enterprise Method tracks.
-
-### DoD (Definition of Done)
-
-Criteria that must be met before marking a story as done. Typically includes: implementation complete, tests written and passing, code reviewed, documentation updated, and acceptance criteria validated.
-
-### Shard / Sharding
-
-**For runtime LLM optimization only (NOT human docs).** Splitting large planning documents (PRD, epics, architecture) into smaller section-based files to improve workflow efficiency. Phase 1-3 workflows load entire sharded documents transparently. Phase 4 workflows selectively load only needed sections for massive token savings.
-
----
+| Term                    | Definition                                                                                                                                 |
+| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Context Engineering** | Loading domain-specific standards into AI context automatically via manifests, ensuring consistent outputs regardless of prompt variation. |
+| **Correct Course**      | Workflow for navigating significant changes when implementation is off-track. Analyzes impact and recommends adjustments.                  |
+| **Shard / Sharding**    | Splitting large planning documents into section-based files for LLM optimization. Phase 4 workflows load only needed sections.             |
+| **Sprint**              | Time-boxed period of development work, typically 1-2 weeks.                                                                                |
+| **Sprint Planning**     | Workflow initializing Phase 4 by creating sprint-status.yaml and extracting epics/stories from planning docs.                              |
+| **Story**               | Single unit of implementable work with clear acceptance criteria, typically 2-8 hours of effort. Grouped into epics.                       |
+| **Story Context**       | Implementation guidance embedded in story files during create-story, referencing existing patterns and approaches.                         |
+| **Story File**          | Markdown file containing story description, acceptance criteria, technical notes, and testing requirements.                                |
+| **Track Selection**     | Automatic analysis by workflow-init suggesting appropriate track based on complexity indicators. User can override.                        |
 
 ## Game Development Terms
 
-### Core Fantasy
+| Term                           | Definition                                                                                           |
+| ------------------------------ | ---------------------------------------------------------------------------------------------------- |
+| **Core Fantasy**               | *BMGD.* The emotional experience players seek from your game — what they want to FEEL.               |
+| **Core Loop**                  | *BMGD.* Fundamental cycle of actions players repeat throughout gameplay. The heart of your game.     |
+| **Design Pillar**              | *BMGD.* Core principle guiding all design decisions. Typically 3-5 pillars define a game's identity. |
+| **Environmental Storytelling** | *BMGD.* Narrative communicated through the game world itself rather than explicit dialogue.          |
+| **Game Type**                  | *BMGD.* Genre classification determining which specialized GDD sections are included.                |
+| **MDA Framework**              | *BMGD.* Mechanics → Dynamics → Aesthetics — framework for analyzing and designing games.             |
+| **Meta-Progression**           | *BMGD.* Persistent progression carrying between individual runs or sessions.                         |
+| **Metroidvania**               | *BMGD.* Genre featuring interconnected world exploration with ability-gated progression.             |
+| **Narrative Complexity**       | *BMGD.* How central story is to the game: Critical, Heavy, Moderate, or Light.                       |
+| **Permadeath**                 | *BMGD.* Game mechanic where character death is permanent, typically requiring a new run.             |
+| **Player Agency**              | *BMGD.* Degree to which players can make meaningful choices affecting outcomes.                      |
+| **Procedural Generation**      | *BMGD.* Algorithmic creation of game content (levels, items, characters) rather than hand-crafted.   |
+| **Roguelike**                  | *BMGD.* Genre featuring procedural generation, permadeath, and run-based progression.                |
 
-The emotional experience players seek from your game. What they want to FEEL.
+## Test Architect (TEA) Concepts
 
-### Core Loop
-
-The fundamental cycle of actions players repeat throughout gameplay. The heart of your game.
-
-### Design Pillar
-
-Core principle that guides all design decisions. Typically 3-5 pillars define a game's identity.
-
-### Game Type
-
-Genre classification that determines which specialized GDD sections are included.
-
-### Narrative Complexity
-
-How central story is to the game experience:
-- **Critical** - Story IS the game (visual novels)
-- **Heavy** - Deep narrative with gameplay (RPGs)
-- **Moderate** - Meaningful story supporting gameplay
-- **Light** - Minimal story, gameplay-focused
-
-### Environmental Storytelling
-
-Narrative communicated through the game world itself—visual details, audio, found documents—rather than explicit dialogue.
-
-### MDA Framework
-
-Mechanics → Dynamics → Aesthetics. Framework for analyzing and designing games.
-
-### Procedural Generation
-
-Algorithmic creation of game content (levels, items, characters) rather than hand-crafted.
-
-### Roguelike
-
-Genre featuring procedural generation, permadeath, and run-based progression.
-
-### Metroidvania
-
-Genre featuring interconnected world exploration with ability-gated progression.
-
-### Meta-Progression
-
-Persistent progression that carries between individual runs or sessions.
-
-### Permadeath
-
-Game mechanic where character death is permanent, typically requiring a new run.
-
-### Player Agency
-
-The degree to which players can make meaningful choices that affect outcomes.
+| Term                         | Definition                                                                                                                                                    |
+| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **ATDD**                     | Acceptance Test-Driven Development — Generating failing acceptance tests BEFORE implementation (TDD red phase).                                               |
+| **Burn-in Testing**          | Running tests multiple times (typically 5-10 iterations) to detect flakiness and intermittent failures.                                                       |
+| **Component Testing**        | Testing UI components in isolation using framework-specific tools (Cypress Component Testing or Vitest + React Testing Library).                              |
+| **Coverage Traceability**    | Mapping acceptance criteria to implemented tests with classification (FULL/PARTIAL/NONE) to identify gaps and measure completeness.                           |
+| **Epic-Level Test Design**   | Test planning per epic (Phase 4) focusing on risk assessment, priorities, and coverage strategy for that specific epic.                                       |
+| **Fixture Architecture**     | Pattern of building pure functions first, then wrapping in framework-specific fixtures for testability, reusability, and composition.                         |
+| **Gate Decision**            | Go/no-go decision for release with four outcomes: PASS ✅ (ready), CONCERNS ⚠️ (proceed with mitigation), FAIL ❌ (blocked), WAIVED ⏭️ (approved despite issues). |
+| **Knowledge Fragment**       | Individual markdown file in TEA's knowledge base covering a specific testing pattern or practice (33 fragments total).                                        |
+| **MCP Enhancements**         | Model Context Protocol servers enabling live browser verification during test generation (exploratory, recording, and healing modes).                         |
+| **Network-First Pattern**    | Testing pattern that waits for actual network responses instead of fixed timeouts to avoid race conditions and flakiness.                                     |
+| **NFR Assessment**           | Validation of non-functional requirements (security, performance, reliability, maintainability) with evidence-based decisions.                                |
+| **Playwright Utils**         | Optional package (`@seontechnologies/playwright-utils`) providing production-ready fixtures and utilities for Playwright tests.                               |
+| **Risk-Based Testing**       | Testing approach where depth scales with business impact using probability × impact scoring (1-9 scale).                                                      |
+| **System-Level Test Design** | Test planning at architecture level (Phase 3) focusing on testability review, ADR mapping, and test infrastructure needs.                                     |
+| **tea-index.csv**            | Manifest file tracking all knowledge fragments, their descriptions, tags, and which workflows load them.                                                      |
+| **TEA Integrated**           | Full BMad Method integration with TEA workflows across all phases (Phase 2, 3, 4, and Release Gate).                                                          |
+| **TEA Lite**                 | Beginner approach using just `*automate` workflow to test existing features (simplest way to use TEA).                                                        |
+| **TEA Solo**                 | Standalone engagement model using TEA without full BMad Method integration (bring your own requirements).                                                     |
+| **Test Priorities**          | Classification system for test importance: P0 (critical path), P1 (high value), P2 (medium value), P3 (low value).                                            |
 
 ---
 
-## Additional Terms
+## See Also
 
-### Workflow Status
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Complete TEA capabilities
+- [TEA Knowledge Base](/docs/reference/tea/knowledge-base.md) - Fragment index
+- [TEA Command Reference](/docs/reference/tea/commands.md) - Workflow reference
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Config options
 
-Universal entry point workflow that checks for existing status file, displays current phase/progress, and recommends next action based on project state.
+---
 
-### Workflow Init
-
-Initialization workflow that creates bmm-workflow-status.yaml, detects greenfield vs brownfield, determines planning track, and sets up appropriate workflow path.
-
-### Track Selection
-
-Automatic analysis by workflow-init that uses keyword analysis, complexity indicators, and project requirements to suggest appropriate track (Quick Flow, BMad Method, or Enterprise Method). User can override suggested track.
-
-### Correct Course
-
-Workflow run during Phase 4 when significant changes or issues arise. Analyzes impact, proposes solutions, and routes to appropriate remediation workflows.
-
-### Feature Flags
-
-Implementation technique for brownfield projects that allows gradual rollout of new functionality, easy rollback, and A/B testing. Recommended for BMad Method and Enterprise brownfield changes.
-
-### Integration Points
-
-Specific locations where new code connects with existing systems. Must be documented explicitly in brownfield tech-specs and architectures.
-
-### Context Engineering
-
-Loading domain-specific standards and patterns into AI context automatically, rather than relying on prompts alone. In TEA, this means the `tea-index.csv` manifest loads relevant knowledge fragments so the AI doesn't relearn testing patterns each session. This approach ensures consistent, production-ready outputs regardless of prompt variation.
-
-### Convention Detection
-
-Quick Spec Flow feature that automatically detects existing code style, naming conventions, patterns, and frameworks from brownfield codebases, then asks user to confirm before proceeding.
+Generated with [BMad Method](https://bmad-method.org)

docs/reference/tea/commands.md

@@ -0,0 +1,254 @@
+---
+title: "TEA Command Reference"
+description: Quick reference for all 8 TEA workflows - inputs, outputs, and links to detailed guides
+---
+
+# TEA Command Reference
+
+Quick reference for all 8 TEA (Test Architect) workflows. For detailed step-by-step guides, see the how-to documentation.
+
+## Quick Index
+
+- [*framework](#framework) - Scaffold test framework
+- [*ci](#ci) - Setup CI/CD pipeline
+- [*test-design](#test-design) - Risk-based test planning
+- [*atdd](#atdd) - Acceptance TDD
+- [*automate](#automate) - Test automation
+- [*test-review](#test-review) - Quality audit
+- [*nfr-assess](#nfr-assess) - NFR assessment
+- [*trace](#trace) - Coverage traceability
+
+---
+
+## *framework
+
+**Purpose:** Scaffold production-ready test framework (Playwright or Cypress)
+
+**Phase:** Phase 3 (Solutioning)
+
+**Frequency:** Once per project
+
+**Key Inputs:**
+- Tech stack, test framework choice, testing scope
+
+**Key Outputs:**
+- `tests/` directory with `support/fixtures/` and `support/helpers/`
+- `playwright.config.ts` or `cypress.config.ts`
+- `.env.example`, `.nvmrc`
+- Sample tests with best practices
+
+**How-To Guide:** [Setup Test Framework](/docs/how-to/workflows/setup-test-framework.md)
+
+---
+
+## *ci
+
+**Purpose:** Setup CI/CD pipeline with selective testing and burn-in
+
+**Phase:** Phase 3 (Solutioning)
+
+**Frequency:** Once per project
+
+**Key Inputs:**
+- CI platform (GitHub Actions, GitLab CI, etc.)
+- Sharding strategy, burn-in preferences
+
+**Key Outputs:**
+- Platform-specific CI workflow (`.github/workflows/test.yml`, etc.)
+- Parallel execution configuration
+- Burn-in loops for flakiness detection
+- Secrets checklist
+
+**How-To Guide:** [Setup CI Pipeline](/docs/how-to/workflows/setup-ci.md)
+
+---
+
+## *test-design
+
+**Purpose:** Risk-based test planning with coverage strategy
+
+**Phase:** Phase 3 (system-level), Phase 4 (epic-level)
+
+**Frequency:** Once (system), per epic (epic-level)
+
+**Modes:**
+- **System-level:** Architecture testability review
+- **Epic-level:** Per-epic risk assessment
+
+**Key Inputs:**
+- Architecture/epic, requirements, ADRs
+
+**Key Outputs:**
+- `test-design-system.md` or `test-design-epic-N.md`
+- Risk assessment (probability × impact scores)
+- Test priorities (P0-P3)
+- Coverage strategy
+
+**MCP Enhancement:** Exploratory mode (live browser UI discovery)
+
+**How-To Guide:** [Run Test Design](/docs/how-to/workflows/run-test-design.md)
+
+---
+
+## *atdd
+
+**Purpose:** Generate failing acceptance tests BEFORE implementation (TDD red phase)
+
+**Phase:** Phase 4 (Implementation)
+
+**Frequency:** Per story (optional)
+
+**Key Inputs:**
+- Story with acceptance criteria, test design, test levels
+
+**Key Outputs:**
+- Failing tests (`tests/api/`, `tests/e2e/`)
+- Implementation checklist
+- All tests fail initially (red phase)
+
+**MCP Enhancement:** Recording mode (for skeleton UI only - rare)
+
+**How-To Guide:** [Run ATDD](/docs/how-to/workflows/run-atdd.md)
+
+---
+
+## *automate
+
+**Purpose:** Expand test coverage after implementation
+
+**Phase:** Phase 4 (Implementation)
+
+**Frequency:** Per story/feature
+
+**Key Inputs:**
+- Feature description, test design, existing tests to avoid duplication
+
+**Key Outputs:**
+- Comprehensive test suite (`tests/e2e/`, `tests/api/`)
+- Updated fixtures, README
+- Definition of Done summary
+
+**MCP Enhancement:** Healing + Recording modes (fix tests, verify selectors)
+
+**How-To Guide:** [Run Automate](/docs/how-to/workflows/run-automate.md)
+
+---
+
+## *test-review
+
+**Purpose:** Audit test quality with 0-100 scoring
+
+**Phase:** Phase 4 (optional per story), Release Gate
+
+**Frequency:** Per epic or before release
+
+**Key Inputs:**
+- Test scope (file, directory, or entire suite)
+
+**Key Outputs:**
+- `test-review.md` with quality score (0-100)
+- Critical issues with fixes
+- Recommendations
+- Category scores (Determinism, Isolation, Assertions, Structure, Performance)
+
+**Scoring Categories:**
+- Determinism: 35 points
+- Isolation: 25 points
+- Assertions: 20 points
+- Structure: 10 points
+- Performance: 10 points
+
+**How-To Guide:** [Run Test Review](/docs/how-to/workflows/run-test-review.md)
+
+---
+
+## *nfr-assess
+
+**Purpose:** Validate non-functional requirements with evidence
+
+**Phase:** Phase 2 (enterprise), Release Gate
+
+**Frequency:** Per release (enterprise projects)
+
+**Key Inputs:**
+- NFR categories (Security, Performance, Reliability, Maintainability)
+- Thresholds, evidence location
+
+**Key Outputs:**
+- `nfr-assessment.md`
+- Category assessments (PASS/CONCERNS/FAIL)
+- Mitigation plans
+- Gate decision inputs
+
+**How-To Guide:** [Run NFR Assessment](/docs/how-to/workflows/run-nfr-assess.md)
+
+---
+
+## *trace
+
+**Purpose:** Requirements traceability + quality gate decision
+
+**Phase:** Phase 2/4 (traceability), Release Gate (decision)
+
+**Frequency:** Baseline, per epic refresh, release gate
+
+**Two-Phase Workflow:**
+
+**Phase 1: Traceability**
+- Requirements → test mapping
+- Coverage classification (FULL/PARTIAL/NONE)
+- Gap prioritization
+- Output: `traceability-matrix.md`
+
+**Phase 2: Gate Decision**
+- PASS/CONCERNS/FAIL/WAIVED decision
+- Evidence-based (coverage %, quality scores, NFRs)
+- Output: `gate-decision-{gate_type}-{story_id}.md`
+
+**Gate Rules:**
+- P0 coverage: 100% required
+- P1 coverage: ≥90% for PASS, 80-89% for CONCERNS, <80% FAIL
+- Overall coverage: ≥80% required
+
+**How-To Guide:** [Run Trace](/docs/how-to/workflows/run-trace.md)
+
+---
+
+## Summary Table
+
+| Command | Phase | Frequency | Primary Output |
+|---------|-------|-----------|----------------|
+| `*framework` | 3 | Once | Test infrastructure |
+| `*ci` | 3 | Once | CI/CD pipeline |
+| `*test-design` | 3, 4 | System + per epic | Test design doc |
+| `*atdd` | 4 | Per story (optional) | Failing tests |
+| `*automate` | 4 | Per story | Passing tests |
+| `*test-review` | 4, Gate | Per epic/release | Quality report |
+| `*nfr-assess` | 2, Gate | Per release | NFR assessment |
+| `*trace` | 2, 4, Gate | Baseline + refresh + gate | Coverage matrix + decision |
+
+---
+
+## See Also
+
+**How-To Guides (Detailed Instructions):**
+- [Setup Test Framework](/docs/how-to/workflows/setup-test-framework.md)
+- [Setup CI Pipeline](/docs/how-to/workflows/setup-ci.md)
+- [Run Test Design](/docs/how-to/workflows/run-test-design.md)
+- [Run ATDD](/docs/how-to/workflows/run-atdd.md)
+- [Run Automate](/docs/how-to/workflows/run-automate.md)
+- [Run Test Review](/docs/how-to/workflows/run-test-review.md)
+- [Run NFR Assessment](/docs/how-to/workflows/run-nfr-assess.md)
+- [Run Trace](/docs/how-to/workflows/run-trace.md)
+
+**Explanation:**
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Complete TEA lifecycle
+- [Engagement Models](/docs/explanation/tea/engagement-models.md) - When to use which workflows
+
+**Reference:**
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Config options
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md) - Pattern fragments
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/reference/tea/configuration.md

@@ -0,0 +1,678 @@
+---
+title: "TEA Configuration Reference"
+description: Complete reference for TEA configuration options and file locations
+---
+
+# TEA Configuration Reference
+
+Complete reference for all TEA (Test Architect) configuration options.
+
+## Configuration File Locations
+
+### User Configuration (Installer-Generated)
+
+**Location:** `_bmad/bmm/config.yaml`
+
+**Purpose:** Project-specific configuration values for your repository
+
+**Created By:** BMad installer
+
+**Status:** Typically gitignored (user-specific values)
+
+**Usage:** Edit this file to change TEA behavior in your project
+
+**Example:**
+```yaml
+# _bmad/bmm/config.yaml
+project_name: my-awesome-app
+user_skill_level: intermediate
+output_folder: _bmad-output
+tea_use_playwright_utils: true
+tea_use_mcp_enhancements: false
+```
+
+### Canonical Schema (Source of Truth)
+
+**Location:** `src/modules/bmm/module.yaml`
+
+**Purpose:** Defines available configuration keys, defaults, and installer prompts
+
+**Created By:** BMAD maintainers (part of BMAD repo)
+
+**Status:** Versioned in BMAD repository
+
+**Usage:** Reference only (do not edit unless contributing to BMAD)
+
+**Note:** The installer reads `module.yaml` to prompt for config values, then writes user choices to `_bmad/bmm/config.yaml` in your project.
+
+---
+
+## TEA Configuration Options
+
+### tea_use_playwright_utils
+
+Enable Playwright Utils integration for production-ready fixtures and utilities.
+
+**Schema Location:** `src/modules/bmm/module.yaml:52-56`
+
+**User Config:** `_bmad/bmm/config.yaml`
+
+**Type:** `boolean`
+
+**Default:** `false` (set via installer prompt during installation)
+
+**Installer Prompt:**
+```
+Are you using playwright-utils (@seontechnologies/playwright-utils) in your project?
+You must install packages yourself, or use test architect's *framework command.
+```
+
+**Purpose:** Enables TEA to:
+- Include playwright-utils in `*framework` scaffold
+- Generate tests using playwright-utils fixtures
+- Review tests against playwright-utils patterns
+- Configure CI with burn-in and selective testing utilities
+
+**Affects Workflows:**
+- `*framework` - Includes playwright-utils imports and fixture examples
+- `*atdd` - Uses fixtures like `apiRequest`, `authSession` in generated tests
+- `*automate` - Leverages utilities for test patterns
+- `*test-review` - Reviews against playwright-utils best practices
+- `*ci` - Includes burn-in utility and selective testing
+
+**Example (Enable):**
+```yaml
+tea_use_playwright_utils: true
+```
+
+**Example (Disable):**
+```yaml
+tea_use_playwright_utils: false
+```
+
+**Prerequisites:**
+```bash
+npm install -D @seontechnologies/playwright-utils
+```
+
+**Related:**
+- [Integrate Playwright Utils Guide](/docs/how-to/customization/integrate-playwright-utils.md)
+- [Playwright Utils on npm](https://www.npmjs.com/package/@seontechnologies/playwright-utils)
+
+---
+
+### tea_use_mcp_enhancements
+
+Enable Playwright MCP servers for live browser verification during test generation.
+
+**Schema Location:** `src/modules/bmm/module.yaml:47-50`
+
+**User Config:** `_bmad/bmm/config.yaml`
+
+**Type:** `boolean`
+
+**Default:** `false`
+
+**Installer Prompt:**
+```
+Test Architect Playwright MCP capabilities (healing, exploratory, verification) are optionally available.
+You will have to setup your MCPs yourself; refer to https://docs.bmad-method.org/explanation/features/tea-overview for configuration examples.
+Would you like to enable MCP enhancements in Test Architect?
+```
+
+**Purpose:** Enables TEA to use Model Context Protocol servers for:
+- Live browser automation during test design
+- Selector verification with actual DOM
+- Interactive UI discovery
+- Visual debugging and healing
+
+**Affects Workflows:**
+- `*test-design` - Enables exploratory mode (browser-based UI discovery)
+- `*atdd` - Enables recording mode (verify selectors with live browser)
+- `*automate` - Enables healing mode (fix tests with visual debugging)
+
+**MCP Servers Required:**
+
+**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`)
+
+**Configuration example**:
+
+```json
+{
+  "mcpServers": {
+    "playwright": {
+      "command": "npx",
+      "args": ["@playwright/mcp@latest"]
+    },
+    "playwright-test": {
+      "command": "npx",
+      "args": ["playwright", "run-test-mcp-server"]
+    }
+  }
+}
+```
+
+**Configuration:** Refer to your AI agent's documentation for MCP server setup instructions.
+
+**Example (Enable):**
+```yaml
+tea_use_mcp_enhancements: true
+```
+
+**Example (Disable):**
+```yaml
+tea_use_mcp_enhancements: false
+```
+
+**Prerequisites:**
+1. MCP servers installed in IDE configuration
+2. `@playwright/mcp` package available globally or locally
+3. Browser binaries installed (`npx playwright install`)
+
+**Related:**
+- [Enable MCP Enhancements Guide](/docs/how-to/customization/enable-tea-mcp-enhancements.md)
+- [TEA Overview - MCP Section](/docs/explanation/features/tea-overview.md#playwright-mcp-enhancements)
+- [Playwright MCP on npm](https://www.npmjs.com/package/@playwright/mcp)
+
+---
+
+## Core BMM Configuration (Inherited by TEA)
+
+TEA also uses core BMM configuration options from `_bmad/bmm/config.yaml`:
+
+### output_folder
+
+**Type:** `string`
+
+**Default:** `_bmad-output`
+
+**Purpose:** Where TEA writes output files (test designs, reports, traceability matrices)
+
+**Example:**
+```yaml
+output_folder: _bmad-output
+```
+
+**TEA Output Files:**
+- `test-design-system.md` (from *test-design system-level)
+- `test-design-epic-N.md` (from *test-design epic-level)
+- `test-review.md` (from *test-review)
+- `traceability-matrix.md` (from *trace Phase 1)
+- `gate-decision-{gate_type}-{story_id}.md` (from *trace Phase 2)
+- `nfr-assessment.md` (from *nfr-assess)
+- `automation-summary.md` (from *automate)
+- `atdd-checklist-{story_id}.md` (from *atdd)
+
+---
+
+### user_skill_level
+
+**Type:** `enum`
+
+**Options:** `beginner` | `intermediate` | `expert`
+
+**Default:** `intermediate`
+
+**Purpose:** Affects how TEA explains concepts in chat responses
+
+**Example:**
+```yaml
+user_skill_level: beginner
+```
+
+**Impact on TEA:**
+- **Beginner:** More detailed explanations, links to concepts, verbose guidance
+- **Intermediate:** Balanced explanations, assumes basic knowledge
+- **Expert:** Concise, technical, minimal hand-holding
+
+---
+
+### project_name
+
+**Type:** `string`
+
+**Default:** Directory name
+
+**Purpose:** Used in TEA-generated documentation and reports
+
+**Example:**
+```yaml
+project_name: my-awesome-app
+```
+
+**Used in:**
+- Report headers
+- Documentation titles
+- CI configuration comments
+
+---
+
+### communication_language
+
+**Type:** `string`
+
+**Default:** `english`
+
+**Purpose:** Language for TEA chat responses
+
+**Example:**
+```yaml
+communication_language: english
+```
+
+**Supported:** Any language (TEA responds in specified language)
+
+---
+
+### document_output_language
+
+**Type:** `string`
+
+**Default:** `english`
+
+**Purpose:** Language for TEA-generated documents (test designs, reports)
+
+**Example:**
+```yaml
+document_output_language: english
+```
+
+**Note:** Can differ from `communication_language` - chat in Spanish, generate docs in English.
+
+---
+
+## Environment Variables
+
+TEA workflows may use environment variables for test configuration.
+
+### Test Framework Variables
+
+**Playwright:**
+```bash
+# .env
+BASE_URL=https://todomvc.com/examples/react/dist/
+API_BASE_URL=https://api.example.com
+TEST_USER_EMAIL=test@example.com
+TEST_USER_PASSWORD=password123
+```
+
+**Cypress:**
+```bash
+# cypress.env.json or .env
+CYPRESS_BASE_URL=https://example.com
+CYPRESS_API_URL=https://api.example.com
+```
+
+### CI/CD Variables
+
+Set in CI platform (GitHub Actions secrets, GitLab CI variables):
+
+```yaml
+# .github/workflows/test.yml
+env:
+  BASE_URL: ${{ secrets.STAGING_URL }}
+  API_KEY: ${{ secrets.API_KEY }}
+  TEST_USER_EMAIL: ${{ secrets.TEST_USER }}
+```
+
+---
+
+## Configuration Patterns
+
+### Development vs Production
+
+**Separate configs for environments:**
+
+```yaml
+# _bmad/bmm/config.yaml
+output_folder: _bmad-output
+
+# .env.development
+BASE_URL=http://localhost:3000
+API_BASE_URL=http://localhost:4000
+
+# .env.staging
+BASE_URL=https://staging.example.com
+API_BASE_URL=https://api-staging.example.com
+
+# .env.production (read-only tests only!)
+BASE_URL=https://example.com
+API_BASE_URL=https://api.example.com
+```
+
+### Team vs Individual
+
+**Team config (committed):**
+```yaml
+# _bmad/bmm/config.yaml.example (committed to repo)
+project_name: team-project
+output_folder: _bmad-output
+tea_use_playwright_utils: true
+tea_use_mcp_enhancements: false
+```
+
+**Individual config (typically gitignored):**
+```yaml
+# _bmad/bmm/config.yaml (user adds to .gitignore)
+user_name: John Doe
+user_skill_level: expert
+tea_use_mcp_enhancements: true  # Individual preference
+```
+
+### Monorepo Configuration
+
+**Root config:**
+```yaml
+# _bmad/bmm/config.yaml (root)
+project_name: monorepo-parent
+output_folder: _bmad-output
+```
+
+**Package-specific:**
+```yaml
+# packages/web-app/_bmad/bmm/config.yaml
+project_name: web-app
+output_folder: ../../_bmad-output/web-app
+tea_use_playwright_utils: true
+
+# packages/mobile-app/_bmad/bmm/config.yaml
+project_name: mobile-app
+output_folder: ../../_bmad-output/mobile-app
+tea_use_playwright_utils: false
+```
+
+---
+
+## Configuration Best Practices
+
+### 1. Use Version Control Wisely
+
+**Commit:**
+```
+_bmad/bmm/config.yaml.example    # Template for team
+.nvmrc                            # Node version
+package.json                      # Dependencies
+```
+
+**Recommended for .gitignore:**
+```
+_bmad/bmm/config.yaml            # User-specific values
+.env                              # Secrets
+.env.local                        # Local overrides
+```
+
+### 2. Document Required Setup
+
+**In your README:**
+```markdown
+## Setup
+
+1. Install BMad
+
+2. Copy config template:
+   cp _bmad/bmm/config.yaml.example _bmad/bmm/config.yaml
+
+3. Edit config with your values:
+   - Set user_name
+   - Enable tea_use_playwright_utils if using playwright-utils
+   - Enable tea_use_mcp_enhancements if MCPs configured
+```
+
+### 3. Validate Configuration
+
+**Check config is valid:**
+```bash
+# Check TEA config is set
+cat _bmad/bmm/config.yaml | grep tea_use
+
+# Verify playwright-utils installed (if enabled)
+npm list @seontechnologies/playwright-utils
+
+# Verify MCP servers configured (if enabled)
+# Check your IDE's MCP settings
+```
+
+### 4. Keep Config Minimal
+
+**Don't over-configure:**
+```yaml
+# ❌ Bad - overriding everything unnecessarily
+project_name: my-project
+user_name: John Doe
+user_skill_level: expert
+output_folder: custom/path
+planning_artifacts: custom/planning
+implementation_artifacts: custom/implementation
+project_knowledge: custom/docs
+tea_use_playwright_utils: true
+tea_use_mcp_enhancements: true
+communication_language: english
+document_output_language: english
+# Overriding 11 config options when most can use defaults
+
+# ✅ Good - only essential overrides
+tea_use_playwright_utils: true
+output_folder: docs/testing
+# Only override what differs from defaults
+```
+
+**Use defaults when possible** - only override what you actually need to change.
+
+---
+
+## Troubleshooting
+
+### Configuration Not Loaded
+
+**Problem:** TEA doesn't use my config values.
+
+**Causes:**
+1. Config file in wrong location
+2. YAML syntax error
+3. Typo in config key
+
+**Solution:**
+```bash
+# Check file exists
+ls -la _bmad/bmm/config.yaml
+
+# Validate YAML syntax
+npm install -g js-yaml
+js-yaml _bmad/bmm/config.yaml
+
+# Check for typos (compare to module.yaml)
+diff _bmad/bmm/config.yaml src/modules/bmm/module.yaml
+```
+
+### Playwright Utils Not Working
+
+**Problem:** `tea_use_playwright_utils: true` but TEA doesn't use utilities.
+
+**Causes:**
+1. Package not installed
+2. Config file not saved
+3. Workflow run before config update
+
+**Solution:**
+```bash
+# Verify package installed
+npm list @seontechnologies/playwright-utils
+
+# Check config value
+grep tea_use_playwright_utils _bmad/bmm/config.yaml
+
+# Re-run workflow in fresh chat
+# (TEA loads config at workflow start)
+```
+
+### MCP Enhancements Not Working
+
+**Problem:** `tea_use_mcp_enhancements: true` but no browser opens.
+
+**Causes:**
+1. MCP servers not configured in IDE
+2. MCP package not installed
+3. Browser binaries missing
+
+**Solution:**
+```bash
+# Check MCP package available
+npx @playwright/mcp@latest --version
+
+# Install browsers
+npx playwright install
+
+# Verify IDE MCP config
+# Check ~/.cursor/config.json or VS Code settings
+```
+
+### Config Changes Not Applied
+
+**Problem:** Updated config but TEA still uses old values.
+
+**Cause:** TEA loads config at workflow start.
+
+**Solution:**
+1. Save `_bmad/bmm/config.yaml`
+2. Start fresh chat
+3. Run TEA workflow
+4. Config will be reloaded
+
+**TEA doesn't reload config mid-chat** - always start fresh chat after config changes.
+
+---
+
+## Configuration Examples
+
+### Recommended Setup (Full Stack)
+
+```yaml
+# _bmad/bmm/config.yaml
+project_name: my-project
+user_skill_level: beginner  # or intermediate/expert
+output_folder: _bmad-output
+tea_use_playwright_utils: true   # Recommended
+tea_use_mcp_enhancements: true   # Recommended
+```
+
+**Why recommended:**
+- Playwright Utils: Production-ready fixtures and utilities
+- MCP enhancements: Live browser verification, visual debugging
+- Together: The three-part stack (see [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md))
+
+**Prerequisites:**
+```bash
+npm install -D @seontechnologies/playwright-utils
+# Configure MCP servers in IDE (see Enable MCP Enhancements guide)
+```
+
+**Best for:** Everyone (beginners learn good patterns from day one)
+
+---
+
+### Minimal Setup (Learning Only)
+
+```yaml
+# _bmad/bmm/config.yaml
+project_name: my-project
+output_folder: _bmad-output
+tea_use_playwright_utils: false
+tea_use_mcp_enhancements: false
+```
+
+**Best for:**
+- First-time TEA users (keep it simple initially)
+- Quick experiments
+- Learning basics before adding integrations
+
+**Note:** Can enable integrations later as you learn
+
+---
+
+### Monorepo Setup
+
+**Root config:**
+```yaml
+# _bmad/bmm/config.yaml (root)
+project_name: monorepo
+output_folder: _bmad-output
+tea_use_playwright_utils: true
+```
+
+**Package configs:**
+```yaml
+# apps/web/_bmad/bmm/config.yaml
+project_name: web-app
+output_folder: ../../_bmad-output/web
+
+# apps/api/_bmad/bmm/config.yaml
+project_name: api-service
+output_folder: ../../_bmad-output/api
+tea_use_playwright_utils: false  # Using vanilla Playwright only
+```
+
+---
+
+### Team Template
+
+**Commit this template:**
+```yaml
+# _bmad/bmm/config.yaml.example
+# Copy to config.yaml and fill in your values
+
+project_name: your-project-name
+user_name: Your Name
+user_skill_level: intermediate  # beginner | intermediate | expert
+output_folder: _bmad-output
+planning_artifacts: _bmad-output/planning-artifacts
+implementation_artifacts: _bmad-output/implementation-artifacts
+project_knowledge: docs
+
+# TEA Configuration (Recommended: Enable both for full stack)
+tea_use_playwright_utils: true   # Recommended - production-ready utilities
+tea_use_mcp_enhancements: true   # Recommended - live browser verification
+
+# Languages
+communication_language: english
+document_output_language: english
+```
+
+**Team instructions:**
+```markdown
+## Setup for New Team Members
+
+1. Clone repo
+2. Copy config template:
+   cp _bmad/bmm/config.yaml.example _bmad/bmm/config.yaml
+3. Edit with your name and preferences
+4. Install dependencies:
+   npm install
+5. (Optional) Enable playwright-utils:
+   npm install -D @seontechnologies/playwright-utils
+   Set tea_use_playwright_utils: true
+```
+
+---
+
+## See Also
+
+### How-To Guides
+- [Set Up Test Framework](/docs/how-to/workflows/setup-test-framework.md)
+- [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md)
+- [Enable MCP Enhancements](/docs/how-to/customization/enable-tea-mcp-enhancements.md)
+
+### Reference
+- [TEA Command Reference](/docs/reference/tea/commands.md)
+- [Knowledge Base Index](/docs/reference/tea/knowledge-base.md)
+- [Glossary](/docs/reference/glossary/index.md)
+
+### Explanation
+- [TEA Overview](/docs/explanation/features/tea-overview.md)
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md)
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/reference/tea/knowledge-base.md

@@ -0,0 +1,340 @@
+---
+title: "TEA Knowledge Base Index"
+description: Complete index of TEA's 33 knowledge fragments for context engineering
+---
+
+# TEA Knowledge Base Index
+
+TEA uses 33 specialized knowledge fragments for context engineering. These fragments are loaded dynamically based on workflow needs via the `tea-index.csv` manifest.
+
+## What is Context Engineering?
+
+**Context engineering** is the practice of loading domain-specific standards into AI context automatically rather than relying on prompts alone.
+
+Instead of asking AI to "write good tests" every time, TEA:
+1. Reads `tea-index.csv` to identify relevant fragments for the workflow
+2. Loads only the fragments needed (keeps context focused)
+3. Operates with domain-specific standards, not generic knowledge
+4. Produces consistent, production-ready tests across projects
+
+**Example:**
+```
+User runs: *test-design
+
+TEA reads tea-index.csv:
+- Loads: test-quality.md, test-priorities-matrix.md, risk-governance.md
+- Skips: network-recorder.md, burn-in.md (not needed for test design)
+
+Result: Focused context, consistent quality standards
+```
+
+## How Knowledge Loading Works
+
+### 1. Workflow Trigger
+User runs a TEA workflow (e.g., `*test-design`)
+
+### 2. Manifest Lookup
+TEA reads `src/modules/bmm/testarch/tea-index.csv`:
+```csv
+id,name,description,tags,fragment_file
+test-quality,Test Quality,Execution limits and isolation rules,quality;standards,knowledge/test-quality.md
+risk-governance,Risk Governance,Risk scoring and gate decisions,risk;governance,knowledge/risk-governance.md
+```
+
+### 3. Dynamic Loading
+Only fragments needed for the workflow are loaded into context
+
+### 4. Consistent Output
+AI operates with established patterns, producing consistent results
+
+## Fragment Categories
+
+### Architecture & Fixtures
+
+Core patterns for test infrastructure and fixture composition.
+
+| Fragment | Description | Key Topics |
+|----------|-------------|-----------|
+| [fixture-architecture](../../../src/modules/bmm/testarch/knowledge/fixture-architecture.md) | Pure function → Fixture → mergeTests composition with auto-cleanup | Testability, composition, reusability |
+| [network-first](../../../src/modules/bmm/testarch/knowledge/network-first.md) | Intercept-before-navigate workflow, HAR capture, deterministic waits | Flakiness prevention, network patterns |
+| [playwright-config](../../../src/modules/bmm/testarch/knowledge/playwright-config.md) | Environment switching, timeout standards, artifact outputs | Configuration, environments, CI |
+| [fixtures-composition](../../../src/modules/bmm/testarch/knowledge/fixtures-composition.md) | mergeTests composition patterns for combining utilities | Fixture merging, utility composition |
+
+**Used in:** `*framework`, `*test-design`, `*atdd`, `*automate`, `*test-review`
+
+---
+
+### Data & Setup
+
+Patterns for test data generation, authentication, and setup.
+
+| Fragment | Description | Key Topics |
+|----------|-------------|-----------|
+| [data-factories](../../../src/modules/bmm/testarch/knowledge/data-factories.md) | Factory patterns with faker, overrides, API seeding, cleanup | Test data, factories, cleanup |
+| [email-auth](../../../src/modules/bmm/testarch/knowledge/email-auth.md) | Magic link extraction, state preservation, negative flows | Authentication, email testing |
+| [auth-session](../../../src/modules/bmm/testarch/knowledge/auth-session.md) | Token persistence, multi-user, API/browser authentication | Auth patterns, session management |
+
+**Used in:** `*framework`, `*atdd`, `*automate`, `*test-review`
+
+---
+
+### Network & Reliability
+
+Network interception, error handling, and reliability patterns.
+
+| Fragment | Description | Key Topics |
+|----------|-------------|-----------|
+| [network-recorder](../../../src/modules/bmm/testarch/knowledge/network-recorder.md) | HAR record/playback, CRUD detection for offline testing | Offline testing, network replay |
+| [intercept-network-call](../../../src/modules/bmm/testarch/knowledge/intercept-network-call.md) | Network spy/stub, JSON parsing for UI tests | Mocking, interception, stubbing |
+| [error-handling](../../../src/modules/bmm/testarch/knowledge/error-handling.md) | Scoped exception handling, retry validation, telemetry logging | Error patterns, resilience |
+| [network-error-monitor](../../../src/modules/bmm/testarch/knowledge/network-error-monitor.md) | HTTP 4xx/5xx detection for UI tests | Error detection, monitoring |
+
+**Used in:** `*atdd`, `*automate`, `*test-review`
+
+---
+
+### Test Execution & CI
+
+CI/CD patterns, burn-in testing, and selective test execution.
+
+| Fragment | Description | Key Topics |
+|----------|-------------|-----------|
+| [ci-burn-in](../../../src/modules/bmm/testarch/knowledge/ci-burn-in.md) | Staged jobs, shard orchestration, burn-in loops | CI/CD, flakiness detection |
+| [burn-in](../../../src/modules/bmm/testarch/knowledge/burn-in.md) | Smart test selection, git diff for CI optimization | Test selection, performance |
+| [selective-testing](../../../src/modules/bmm/testarch/knowledge/selective-testing.md) | Tag/grep usage, spec filters, diff-based runs | Test filtering, optimization |
+
+**Used in:** `*ci`, `*test-review`
+
+---
+
+### Quality & Standards
+
+Test quality standards, test level selection, and TDD patterns.
+
+| Fragment | Description | Key Topics |
+|----------|-------------|-----------|
+| [test-quality](../../../src/modules/bmm/testarch/knowledge/test-quality.md) | Execution limits, isolation rules, green criteria | DoD, best practices, anti-patterns |
+| [test-levels-framework](../../../src/modules/bmm/testarch/knowledge/test-levels-framework.md) | Guidelines for unit, integration, E2E selection | Test pyramid, level selection |
+| [test-priorities-matrix](../../../src/modules/bmm/testarch/knowledge/test-priorities-matrix.md) | P0-P3 criteria, coverage targets, execution ordering | Prioritization, risk-based testing |
+| [test-healing-patterns](../../../src/modules/bmm/testarch/knowledge/test-healing-patterns.md) | Common failure patterns and automated fixes | Debugging, healing, fixes |
+| [component-tdd](../../../src/modules/bmm/testarch/knowledge/component-tdd.md) | Red→green→refactor workflow, provider isolation | TDD, component testing |
+
+**Used in:** `*test-design`, `*atdd`, `*automate`, `*test-review`, `*trace`
+
+---
+
+### Risk & Gates
+
+Risk assessment, governance, and gate decision frameworks.
+
+| Fragment | Description | Key Topics |
+|----------|-------------|-----------|
+| [risk-governance](../../../src/modules/bmm/testarch/knowledge/risk-governance.md) | Scoring matrix, category ownership, gate decision rules | Risk assessment, governance |
+| [probability-impact](../../../src/modules/bmm/testarch/knowledge/probability-impact.md) | Probability × impact scale for scoring matrix | Risk scoring, impact analysis |
+| [nfr-criteria](../../../src/modules/bmm/testarch/knowledge/nfr-criteria.md) | Security, performance, reliability, maintainability status | NFRs, compliance, enterprise |
+
+**Used in:** `*test-design`, `*nfr-assess`, `*trace`
+
+---
+
+### Selectors & Timing
+
+Selector resilience, race condition debugging, and visual debugging.
+
+| Fragment | Description | Key Topics |
+|----------|-------------|-----------|
+| [selector-resilience](../../../src/modules/bmm/testarch/knowledge/selector-resilience.md) | Robust selector strategies and debugging | Selectors, locators, resilience |
+| [timing-debugging](../../../src/modules/bmm/testarch/knowledge/timing-debugging.md) | Race condition identification and deterministic fixes | Race conditions, timing issues |
+| [visual-debugging](../../../src/modules/bmm/testarch/knowledge/visual-debugging.md) | Trace viewer usage, artifact expectations | Debugging, trace viewer, artifacts |
+
+**Used in:** `*atdd`, `*automate`, `*test-review`
+
+---
+
+### Feature Flags & Testing Patterns
+
+Feature flag testing, contract testing, and API testing patterns.
+
+| Fragment | Description | Key Topics |
+|----------|-------------|-----------|
+| [feature-flags](../../../src/modules/bmm/testarch/knowledge/feature-flags.md) | Enum management, targeting helpers, cleanup, checklists | Feature flags, toggles |
+| [contract-testing](../../../src/modules/bmm/testarch/knowledge/contract-testing.md) | Pact publishing, provider verification, resilience | Contract testing, Pact |
+| [api-testing-patterns](../../../src/modules/bmm/testarch/knowledge/api-testing-patterns.md) | Pure API patterns without browser | API testing, backend testing |
+
+**Used in:** `*test-design`, `*atdd`, `*automate`
+
+---
+
+### Playwright-Utils Integration
+
+Patterns for using `@seontechnologies/playwright-utils` package (9 utilities).
+
+| Fragment | Description | Key Topics |
+|----------|-------------|-----------|
+| [api-request](../../../src/modules/bmm/testarch/knowledge/api-request.md) | Typed HTTP client, schema validation, retry logic | API calls, HTTP, validation |
+| [auth-session](../../../src/modules/bmm/testarch/knowledge/auth-session.md) | Token persistence, multi-user, API/browser authentication | Auth patterns, session management |
+| [network-recorder](../../../src/modules/bmm/testarch/knowledge/network-recorder.md) | HAR record/playback, CRUD detection for offline testing | Offline testing, network replay |
+| [intercept-network-call](../../../src/modules/bmm/testarch/knowledge/intercept-network-call.md) | Network spy/stub, JSON parsing for UI tests | Mocking, interception, stubbing |
+| [recurse](../../../src/modules/bmm/testarch/knowledge/recurse.md) | Async polling for API responses, background jobs | Polling, eventual consistency |
+| [log](../../../src/modules/bmm/testarch/knowledge/log.md) | Structured logging for API and UI tests | Logging, debugging, reporting |
+| [file-utils](../../../src/modules/bmm/testarch/knowledge/file-utils.md) | CSV/XLSX/PDF/ZIP handling with download support | File validation, exports |
+| [burn-in](../../../src/modules/bmm/testarch/knowledge/burn-in.md) | Smart test selection with git diff analysis | CI optimization, selective testing |
+| [network-error-monitor](../../../src/modules/bmm/testarch/knowledge/network-error-monitor.md) | Auto-detect HTTP 4xx/5xx errors during tests | Error monitoring, silent failures |
+
+**Note:** `fixtures-composition` is listed under Architecture & Fixtures (general Playwright `mergeTests` pattern, applies to all fixtures).
+
+**Used in:** `*framework` (if `tea_use_playwright_utils: true`), `*atdd`, `*automate`, `*test-review`, `*ci`
+
+**Official Docs:** <https://seontechnologies.github.io/playwright-utils/>
+
+---
+
+## Fragment Manifest (tea-index.csv)
+
+**Location:** `src/modules/bmm/testarch/tea-index.csv`
+
+**Purpose:** Tracks all knowledge fragments and their usage in workflows
+
+**Structure:**
+```csv
+id,name,description,tags,fragment_file
+test-quality,Test Quality,Execution limits and isolation rules,quality;standards,knowledge/test-quality.md
+risk-governance,Risk Governance,Risk scoring and gate decisions,risk;governance,knowledge/risk-governance.md
+```
+
+**Columns:**
+- `id` - Unique fragment identifier (kebab-case)
+- `name` - Human-readable fragment name
+- `description` - What the fragment covers
+- `tags` - Searchable tags (semicolon-separated)
+- `fragment_file` - Relative path to fragment markdown file
+
+**Fragment Location:** `src/modules/bmm/testarch/knowledge/` (all 33 fragments in single directory)
+
+**Manifest:** `src/modules/bmm/testarch/tea-index.csv`
+
+---
+
+## Workflow Fragment Loading
+
+Each TEA workflow loads specific fragments:
+
+### *framework
+**Key Fragments:**
+- fixture-architecture.md
+- playwright-config.md
+- fixtures-composition.md
+
+**Purpose:** Test infrastructure patterns and fixture composition
+
+**Note:** Loads additional fragments based on framework choice (Playwright/Cypress) and config (`tea_use_playwright_utils`).
+
+---
+
+### *test-design
+**Key Fragments:**
+- test-quality.md
+- test-priorities-matrix.md
+- test-levels-framework.md
+- risk-governance.md
+- probability-impact.md
+
+**Purpose:** Risk assessment and test planning standards
+
+**Note:** Loads additional fragments based on mode (system-level vs epic-level) and focus areas.
+
+---
+
+### *atdd
+**Key Fragments:**
+- test-quality.md
+- component-tdd.md
+- fixture-architecture.md
+- network-first.md
+- data-factories.md
+- selector-resilience.md
+- timing-debugging.md
+- test-healing-patterns.md
+
+**Purpose:** TDD patterns and test generation standards
+
+**Note:** Loads auth, network, and utility fragments based on feature requirements.
+
+---
+
+### *automate
+**Key Fragments:**
+- test-quality.md
+- test-levels-framework.md
+- test-priorities-matrix.md
+- fixture-architecture.md
+- network-first.md
+- selector-resilience.md
+- test-healing-patterns.md
+- timing-debugging.md
+
+**Purpose:** Comprehensive test generation with quality standards
+
+**Note:** Loads additional fragments for data factories, auth, network utilities based on test needs.
+
+---
+
+### *test-review
+**Key Fragments:**
+- test-quality.md
+- test-healing-patterns.md
+- selector-resilience.md
+- timing-debugging.md
+- visual-debugging.md
+- network-first.md
+- test-levels-framework.md
+- fixture-architecture.md
+
+**Purpose:** Comprehensive quality review against all standards
+
+**Note:** Loads all applicable playwright-utils fragments when `tea_use_playwright_utils: true`.
+
+---
+
+### *ci
+**Key Fragments:**
+- ci-burn-in.md
+- burn-in.md
+- selective-testing.md
+- playwright-config.md
+
+**Purpose:** CI/CD best practices and optimization
+
+---
+
+### *nfr-assess
+**Key Fragments:**
+- nfr-criteria.md
+- risk-governance.md
+- probability-impact.md
+
+**Purpose:** NFR assessment frameworks and decision rules
+
+---
+
+### *trace
+**Key Fragments:**
+- test-priorities-matrix.md
+- risk-governance.md
+- test-quality.md
+
+**Purpose:** Traceability and gate decision standards
+
+**Note:** Loads nfr-criteria.md if NFR assessment is part of gate decision.
+
+---
+
+## Related
+
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - How knowledge base fits in TEA
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - Context engineering philosophy
+- [TEA Command Reference](/docs/reference/tea/commands.md) - Workflows that use fragments
+
+---
+
+Generated with [BMad Method](https://bmad-method.org) - TEA (Test Architect)

docs/reference/workflows/bmgd-workflows.md

@@ -2,19 +2,14 @@
 title: "BMGD Workflows Guide"
 ---
 
-
 Complete reference for all BMGD workflows organized by development phase.
 
----
-
-## Workflow Overview
+## Overview
 
 BMGD workflows are organized into four phases:
 
 ![BMGD Workflow Overview](../../tutorials/getting-started/images/workflow-overview.jpg)
 
----
-
 ## Phase 1: Preproduction
 
 ### Brainstorm Game
@@ -24,23 +19,19 @@ BMGD workflows are organized into four phases:
 **Input:** None required
 **Output:** Ideas and concepts (optionally saved)
 
-**Description:**
 Guided ideation session using game-specific brainstorming techniques:
 
-- **MDA Framework** - Mechanics → Dynamics → Aesthetics analysis
-- **Core Loop Workshop** - Define the fundamental gameplay loop
-- **Player Fantasy Mining** - Explore what players want to feel
-- **Genre Mashup** - Combine genres for unique concepts
+- **MDA Framework** — Mechanics → Dynamics → Aesthetics analysis
+- **Core Loop Workshop** — Define the fundamental gameplay loop
+- **Player Fantasy Mining** — Explore what players want to feel
+- **Genre Mashup** — Combine genres for unique concepts
 
 **Steps:**
-
 1. Initialize brainstorm session
 2. Load game-specific techniques
 3. Execute ideation with selected techniques
 4. Summarize and (optionally) hand off to Game Brief
 
----
-
 ### Game Brief
 
 **Command:** `create-game-brief`
@@ -48,11 +39,9 @@ Guided ideation session using game-specific brainstorming techniques:
 **Input:** Ideas from brainstorming (optional)
 **Output:** `{output_folder}/game-brief.md`
 
-**Description:**
-Captures your game's core vision and fundamentals. This is the foundation for all subsequent design work.
+Captures your game's core vision and fundamentals. Foundation for all subsequent design work.
 
 **Sections covered:**
-
 - Game concept and vision
 - Design pillars (3-5 core principles)
 - Target audience and market
@@ -60,8 +49,6 @@ Captures your game's core vision and fundamentals. This is the foundation for al
 - Core gameplay loop
 - Initial scope definition
 
----
-
 ## Phase 2: Design
 
 ### GDD (Game Design Document)
@@ -71,11 +58,9 @@ Captures your game's core vision and fundamentals. This is the foundation for al
 **Input:** Game Brief
 **Output:** `{output_folder}/gdd.md` (or sharded into `{output_folder}/gdd/`)
 
-**Description:**
 Comprehensive game design document with genre-specific sections based on 24 supported game types.
 
 **Core sections:**
-
 1. Executive Summary
 2. Gameplay Systems
 3. Core Mechanics
@@ -88,14 +73,11 @@ Comprehensive game design document with genre-specific sections based on 24 supp
 10. Epic Generation (for sprint planning)
 
 **Features:**
-
 - Game type selection with specialized sections
 - Hybrid game type support
 - Automatic epic generation
 - Scale-adaptive complexity
 
----
-
 ### Narrative Design
 
 **Command:** `narrative`
@@ -103,11 +85,9 @@ Comprehensive game design document with genre-specific sections based on 24 supp
 **Input:** GDD (required), Game Brief (optional)
 **Output:** `{output_folder}/narrative-design.md`
 
-**Description:**
 For story-driven games. Creates comprehensive narrative documentation.
 
 **Sections covered:**
-
 1. Story Foundation (premise, themes, tone)
 2. Story Structure (acts, beats, pacing)
 3. Characters (protagonists, antagonists, supporting, arcs)
@@ -120,13 +100,10 @@ For story-driven games. Creates comprehensive narrative documentation.
 10. Appendices (relationship map, timeline)
 
 **Narrative Complexity Levels:**
-
-- **Critical** - Story IS the game (visual novels, adventure games)
-- **Heavy** - Deep narrative with gameplay (RPGs, story-driven action)
-- **Moderate** - Meaningful story supporting gameplay
-- **Light** - Minimal story, gameplay-focused
-
----
+- **Critical** — Story IS the game (visual novels, adventure games)
+- **Heavy** — Deep narrative with gameplay (RPGs, story-driven action)
+- **Moderate** — Meaningful story supporting gameplay
+- **Light** — Minimal story, gameplay-focused
 
 ## Phase 3: Technical
 
@@ -137,11 +114,9 @@ For story-driven games. Creates comprehensive narrative documentation.
 **Input:** GDD, Narrative Design (optional)
 **Output:** `{output_folder}/game-architecture.md`
 
-**Description:**
 Technical architecture document covering engine selection, system design, and implementation approach.
 
 **Sections covered:**
-
 1. Executive Summary
 2. Engine/Framework Selection
 3. Core Systems Architecture
@@ -153,8 +128,6 @@ Technical architecture document covering engine selection, system design, and im
 9. Build and Deployment
 10. Technical Risks and Mitigations
 
----
-
 ## Phase 4: Production
 
 Production workflows inherit from BMM and add game-specific overrides.
@@ -166,11 +139,8 @@ Production workflows inherit from BMM and add game-specific overrides.
 **Input:** GDD with epics
 **Output:** `{implementation_artifacts}/sprint-status.yaml`
 
-**Description:**
 Generates or updates sprint tracking from epic files. Sets up the sprint backlog and tracking.
 
----
-
 ### Sprint Status
 
 **Command:** `sprint-status`
@@ -178,14 +148,12 @@ Generates or updates sprint tracking from epic files. Sets up the sprint backlog
 **Input:** `sprint-status.yaml`
 **Output:** Sprint summary, risks, next action recommendation
 
-**Description:**
-Summarizes sprint progress, surfaces risks (stale file, orphaned stories, stories in review), and recommends the next workflow to run. Supports three modes:
+Summarizes sprint progress, surfaces risks (stale file, orphaned stories, stories in review), and recommends the next workflow to run.
 
-- **interactive** (default): Displays summary with menu options
-- **validate**: Checks sprint-status.yaml structure
-- **data**: Returns raw data for other workflows
-
----
+**Modes:**
+- **interactive** (default) — Displays summary with menu options
+- **validate** — Checks sprint-status.yaml structure
+- **data** — Returns raw data for other workflows
 
 ### Create Story
 
@@ -194,13 +162,10 @@ Summarizes sprint progress, surfaces risks (stale file, orphaned stories, storie
 **Input:** GDD, Architecture, Epic context
 **Output:** `{output_folder}/epics/{epic-name}/stories/{story-name}.md`
 
-**Description:**
 Creates implementable story drafts with acceptance criteria, tasks, and technical notes. Stories are marked ready-for-dev directly when created.
 
 **Validation:** `validate-create-story`
 
----
-
 ### Dev Story
 
 **Command:** `dev-story`
@@ -208,11 +173,8 @@ Creates implementable story drafts with acceptance criteria, tasks, and technica
 **Input:** Story (ready for dev)
 **Output:** Implemented code
 
-**Description:**
 Implements story tasks following acceptance criteria. Uses TDD approach (red-green-refactor). Updates sprint-status.yaml automatically on completion.
 
----
-
 ### Code Review
 
 **Command:** `code-review`
@@ -220,11 +182,8 @@ Implements story tasks following acceptance criteria. Uses TDD approach (red-gre
 **Input:** Story (ready for review)
 **Output:** Review feedback, approved/needs changes
 
-**Description:**
 Thorough QA code review with game-specific considerations (performance, 60fps, etc.).
 
----
-
 ### Retrospective
 
 **Command:** `epic-retrospective`
@@ -232,11 +191,8 @@ Thorough QA code review with game-specific considerations (performance, 60fps, e
 **Input:** Completed epic
 **Output:** Retrospective document
 
-**Description:**
 Facilitates team retrospective after epic completion. Captures learnings and improvements.
 
----
-
 ### Correct Course
 
 **Command:** `correct-course`
@@ -244,25 +200,18 @@ Facilitates team retrospective after epic completion. Captures learnings and imp
 **Input:** Current project state
 **Output:** Correction plan
 
-**Description:**
 Navigates significant changes when implementation is off-track. Analyzes impact and recommends adjustments.
 
----
-
 ## Workflow Status
 
 **Command:** `workflow-status`
 **Agent:** All agents
-**Output:** Project status summary
 
-**Description:**
 Checks current project status across all phases. Shows completed documents, current phase, and next steps.
 
----
-
 ## Quick-Flow Workflows
 
-Fast-track workflows that skip full planning phases. See **[Quick-Flow Guide](/docs/how-to/workflows/bmgd-quick-flow.md)** for detailed usage.
+Fast-track workflows that skip full planning phases. See [Quick-Flow Guide](/docs/how-to/workflows/bmgd-quick-flow.md) for detailed usage.
 
 ### Quick-Prototype
 
@@ -271,17 +220,13 @@ Fast-track workflows that skip full planning phases. See **[Quick-Flow Guide](/d
 **Input:** Idea or concept to test
 **Output:** Working prototype, playtest results
 
-**Description:**
 Rapid prototyping workflow for testing game mechanics and ideas quickly. Focuses on "feel" over polish.
 
 **Use when:**
-
 - Testing if a mechanic is fun
 - Proving a concept before committing to design
 - Experimenting with gameplay ideas
 
----
-
 ### Quick-Dev
 
 **Command:** `quick-dev`
@@ -289,17 +234,13 @@ Rapid prototyping workflow for testing game mechanics and ideas quickly. Focuses
 **Input:** Tech-spec, prototype, or direct instructions
 **Output:** Implemented feature
 
-**Description:**
 Flexible development workflow with game-specific considerations (performance, feel, integration).
 
 **Use when:**
-
 - Implementing features from tech-specs
 - Building on successful prototypes
 - Making changes that don't need full story workflow
 
----
-
 ## Quality Assurance Workflows
 
 Game testing workflows for automated testing, playtesting, and quality assurance across Unity, Unreal, and Godot.
@@ -311,22 +252,18 @@ Game testing workflows for automated testing, playtesting, and quality assurance
 **Input:** Game project
 **Output:** Configured test framework
 
-**Description:**
 Initialize a production-ready test framework for your game engine:
 
-- **Unity**: Unity Test Framework with Edit Mode and Play Mode tests
-- **Unreal**: Unreal Automation system with functional tests
-- **Godot**: GUT (Godot Unit Test) framework
+- **Unity** — Unity Test Framework with Edit Mode and Play Mode tests
+- **Unreal** — Unreal Automation system with functional tests
+- **Godot** — GUT (Godot Unit Test) framework
 
 **Creates:**
-
 - Test directory structure
 - Framework configuration
 - Sample unit and integration tests
 - Test documentation
 
----
-
 ### Test Design
 
 **Command:** `test-design`
@@ -334,7 +271,6 @@ Initialize a production-ready test framework for your game engine:
 **Input:** GDD, Architecture
 **Output:** `{output_folder}/game-test-design.md`
 
-**Description:**
 Creates comprehensive test scenarios covering:
 
 - Core gameplay mechanics
@@ -344,8 +280,6 @@ Creates comprehensive test scenarios covering:
 
 Uses GIVEN/WHEN/THEN format with priority levels (P0-P3).
 
----
-
 ### Automate
 
 **Command:** `automate`
@@ -353,15 +287,12 @@ Uses GIVEN/WHEN/THEN format with priority levels (P0-P3).
 **Input:** Test design, game code
 **Output:** Automated test files
 
-**Description:**
 Generates engine-appropriate automated tests:
 
 - Unit tests for pure logic
 - Integration tests for system interactions
 - Smoke tests for critical path validation
 
----
-
 ### Playtest Plan
 
 **Command:** `playtest-plan`
@@ -369,7 +300,6 @@ Generates engine-appropriate automated tests:
 **Input:** Build, test objectives
 **Output:** `{output_folder}/playtest-plan.md`
 
-**Description:**
 Creates structured playtesting sessions:
 
 - Session structure (pre/during/post)
@@ -378,12 +308,9 @@ Creates structured playtesting sessions:
 - Analysis templates
 
 **Playtest Types:**
-
-- Internal (team validation)
-- External (unbiased feedback)
-- Focused (specific feature testing)
-
----
+- **Internal** — Team validation
+- **External** — Unbiased feedback
+- **Focused** — Specific feature testing
 
 ### Performance Test
 
@@ -392,7 +319,6 @@ Creates structured playtesting sessions:
 **Input:** Platform targets
 **Output:** `{output_folder}/performance-test-plan.md`
 
-**Description:**
 Designs performance testing strategy:
 
 - Frame rate targets per platform
@@ -401,8 +327,6 @@ Designs performance testing strategy:
 - Benchmark scenarios
 - Profiling methodology
 
----
-
 ### Test Review
 
 **Command:** `test-review`
@@ -410,7 +334,6 @@ Designs performance testing strategy:
 **Input:** Existing test suite
 **Output:** `{output_folder}/test-review-report.md`
 
-**Description:**
 Reviews test quality and coverage:
 
 - Test suite metrics
@@ -418,8 +341,6 @@ Reviews test quality and coverage:
 - Coverage gaps
 - Recommendations
 
----
-
 ## Utility Workflows
 
 ### Party Mode
@@ -427,40 +348,21 @@ Reviews test quality and coverage:
 **Command:** `party-mode`
 **Agent:** All agents
 
-**Description:**
 Brings multiple agents together for collaborative discussion on complex decisions.
 
----
-
 ### Advanced Elicitation
 
 **Command:** `advanced-elicitation`
 **Agent:** All agents (web only)
 
-**Description:**
 Deep exploration techniques to challenge assumptions and surface hidden requirements.
 
----
-
 ## Standalone BMGD Workflows
 
-BMGD Phase 4 workflows are standalone implementations tailored for game development:
+:::note[Implementation Detail]
+BMGD Phase 4 workflows are standalone implementations tailored for game development. They are self-contained with game-specific logic, templates, and checklists — no dependency on BMM workflow files.
+:::
 
 ```yaml
 workflow: '{project-root}/_bmad/bmgd/workflows/4-production/dev-story/workflow.yaml'
 ```
-
-This means:
-
-1. BMGD workflows are self-contained with game-specific logic
-2. Game-focused templates, checklists, and instructions
-3. No dependency on BMM workflow files
-
----
-
-## Next Steps
-
-- **[Quick Start Guide](/docs/tutorials/getting-started/quick-start-bmgd.md)** - Get started with BMGD
-- **[Quick-Flow Guide](/docs/how-to/workflows/bmgd-quick-flow.md)** - Rapid prototyping and development
-- **[Agents Guide](/docs/explanation/game-dev/agents.md)** - Agent reference
-- **[Game Types Guide](/docs/explanation/game-dev/game-types.md)** - Game type templates

docs/reference/workflows/core-workflows.md

@@ -2,32 +2,31 @@
 title: "Core Workflows"
 ---
 
+Domain-agnostic workflows that can be utilized by any BMad-compliant module, workflow, or agent.
 
-Core Workflows are domain-agnostic workflows that can be utilized by any BMad-compliant module, workflow, or agent. These workflows are installed by default and available at any time.
+## Party Mode
 
-## Available Core Workflows
+Orchestrate dynamic multi-agent conversations with your entire BMad team. Engage multiple specialized perspectives simultaneously — each agent maintains their unique personality, expertise, and communication style.
 
-### [Party Mode](/docs/explanation/features/party-mode.md)
+See [Party Mode](/docs/explanation/features/party-mode.md) for detailed usage.
 
-Orchestrate dynamic multi-agent conversations with your entire BMad team. Engage with multiple specialized perspectives simultaneously—each agent maintaining their unique personality, expertise, and communication style.
+## Brainstorming
 
-### [Brainstorming](/docs/explanation/features/brainstorming-techniques.md)
+Facilitate structured creative sessions using 60+ proven ideation techniques. The AI acts as coach and guide, using proven creativity methods to draw out ideas and insights.
 
-Facilitate structured creative sessions using 60+ proven ideation techniques. The AI acts as coach and guide, using proven creativity methods to draw out ideas and insights that are already within you.
+See [Brainstorming Techniques](/docs/explanation/features/brainstorming-techniques.md) for detailed usage.
 
-### [Advanced Elicitation](/docs/explanation/features/advanced-elicitation.md)
+## Advanced Elicitation
 
-Push the LLM to rethink its work through 50+ reasoning methods—the inverse of brainstorming. The LLM applies sophisticated techniques to re-examine and enhance content it has just generated, essentially "LLM brainstorming" to find better approaches and uncover improvements.
+Push the LLM to rethink its work through 50+ reasoning methods — the inverse of brainstorming. The LLM applies sophisticated techniques to re-examine and enhance content it has just generated.
 
----
+See [Advanced Elicitation](/docs/explanation/features/advanced-elicitation.md) for detailed usage.
 
 ## Workflow Integration
 
-Core Workflows are designed to be invoked and configured by other modules. When called from another workflow, they accept contextual parameters to customize the session:
+Core Workflows accept contextual parameters when called from other modules:
 
 - **Topic focus** — Direct the session toward a specific domain or question
 - **Additional personas** (Party Mode) — Inject expert agents into the roster at runtime
 - **Guardrails** (Brainstorming) — Set constraints and boundaries for ideation
 - **Output goals** — Define what the final output needs to accomplish
-
-This allows modules to leverage these workflows' capabilities while maintaining focus on their specific domain and objectives.

docs/reference/workflows/document-project.md

@@ -1,74 +1,73 @@
 ---
-title: "Document Project Workflow - Technical Reference"
+title: "Document Project Workflow"
 ---
 
+Analyzes and documents brownfield projects for AI-assisted development.
 
-**Module:** BMM (BMad Method Module)
+:::note[Quick Facts]
+- **Module:** BMM (BMad Method Module)
+- **Command:** `*document-project`
+- **Agents:** Analyst, Technical Writer
+- **Output:** Master index + documentation files in `{output_folder}`
+:::
 
 ## Purpose
 
-Analyzes and documents brownfield projects by scanning codebase, architecture, and patterns to create comprehensive reference documentation for AI-assisted development. Generates a master index and multiple documentation files tailored to project structure and type.
+Scans your codebase, architecture, and patterns to create comprehensive reference documentation. Generates a master index and multiple documentation files tailored to your project structure and type.
 
 ## How to Invoke
+
 ```bash
-/bmad:bmm:workflows:document-project
+*document-project
 ```
----
 
 ## Scan Levels
 
-Choose the right scan depth for your needs:
+Choose the right depth for your needs:
 
-### 1. Quick Scan (Default)
+### Quick Scan (Default)
 
 **What it does:** Pattern-based analysis without reading source files
-**Reads:** Config files, package manifests, directory structure, README
-**Use when:**
 
+**Reads:** Config files, package manifests, directory structure, README
+
+**Use when:**
 - You need a fast project overview
 - Initial understanding of project structure
 - Planning next steps before deeper analysis
 
-**Does NOT read:** Source code files (`_.js`, `_.ts`, `_.py`, `_.go`, etc.)
-
-### 2. Deep Scan
+### Deep Scan
 
 **What it does:** Reads files in critical directories based on project type
-**Reads:** Files in critical paths defined by documentation requirements
-**Use when:**
 
+**Reads:** Files in critical paths defined by documentation requirements
+
+**Use when:**
 - Creating comprehensive documentation for brownfield PRD
 - Need detailed analysis of key areas
 - Want balance between depth and speed
 
-**Example:** For a web app, reads controllers/, models/, components/, but not every utility file
-
-### 3. Exhaustive Scan
+### Exhaustive Scan
 
 **What it does:** Reads ALL source files in project
-**Reads:** Every source file (excludes node_modules, dist, build, .git)
-**Use when:**
 
+**Reads:** Every source file (excludes node_modules, dist, build, .git)
+
+**Use when:**
 - Complete project analysis needed
 - Migration planning requires full understanding
 - Detailed audit of entire codebase
-- Deep technical debt assessment
 
-**Note:** Deep-dive mode ALWAYS uses exhaustive scan (no choice)
-
----
+:::caution[Deep-Dive Mode]
+Deep-dive mode always uses exhaustive scan — no choice of scan level.
+:::
 
 ## Resumability
 
 The workflow can be interrupted and resumed without losing progress:
 
-- **State Tracking:** Progress saved in `project-scan-report.json`
-- **Auto-Detection:** Workflow detects incomplete runs (<24 hours old)
-- **Resume Prompt:** Choose to resume or start fresh
-- **Step-by-Step:** Resume from exact step where interrupted
-- **Archiving:** Old state files automatically archived
-
-**Related Documentation:**
-
-- [Brownfield Development Guide](/docs/how-to/brownfield/index.md)
-- [Implementation Workflows](/docs/how-to/workflows/run-sprint-planning.md)
+- **State Tracking** — Progress saved in `project-scan-report.json`
+- **Auto-Detection** — Workflow detects incomplete runs (<24 hours old)
+- **Resume Prompt** — Choose to resume or start fresh
+- **Step-by-Step** — Resume from exact step where interrupted
+- **Archiving** — Old state files automatically archived

docs/reference/workflows/index.md

@@ -3,14 +3,13 @@ title: "Workflows Reference"
 description: Reference documentation for BMad Method workflows
 ---
 
-
-Complete reference documentation for all BMad Method workflows.
+Reference documentation for all BMad Method workflows.
 
 ## Core Workflows
 
-- [Core Workflows](/docs/reference/workflows/core-workflows.md) - Domain-agnostic workflows available to all modules
-- [Document Project](/docs/reference/workflows/document-project.md) - Brownfield project documentation workflow
+- [Core Workflows](/docs/reference/workflows/core-workflows.md) — Domain-agnostic workflows available to all modules
+- [Document Project](/docs/reference/workflows/document-project.md) — Brownfield project documentation
 
 ## Module-Specific Workflows
 
-- [BMGD Workflows](/docs/reference/workflows/bmgd-workflows.md) - Game development workflows
+- [BMGD Workflows](/docs/reference/workflows/bmgd-workflows.md) — Game development workflows

docs/tutorials/getting-started/quick-start-bmgd.md

@@ -1,260 +0,0 @@
----
-title: "Getting Started with BMad Game Development"
-description: Build games with BMad's Game Development Module
----
-
-
-Build games faster using AI-powered workflows with specialized game development agents that guide you through preproduction, design, architecture, and implementation.
-
-:::note[Module Extension]
-BMGD (BMad Game Development) is a module that extends BMad Method. You'll need BMad installed first—see the [BMad v6 tutorial](/docs/tutorials/getting-started/getting-started-bmadv6.md) if you haven't installed it yet.
-:::
-
-## What You'll Learn
-
-- Install and configure the BMGD module
-- Understand game development phases and specialized agents
-- Create a Game Brief and Game Design Document (GDD)
-- Progress from concept to working game code
-
-:::note[Prerequisites]
-- **BMad Method installed** — Follow the main installation guide first
-- **A game idea** — Even a rough concept is enough to start
-- **AI-powered IDE** — Claude Code, Cursor, Windsurf, or similar
-:::
-
-:::tip[Quick Path]
-**Install** → `npx bmad-method install` (select BMGD module)
-**Preproduction** → Game Designer creates Game Brief
-**Design** → Game Designer creates GDD (and Narrative if story-driven)
-**Technical** → Game Architect creates Architecture
-**Production** → Game SM manages sprints, Game Dev implements
-**Always use fresh chats** for each workflow to avoid context issues.
-:::
-
-## Understanding BMGD
-
-BMGD follows four game development phases with specialized agents for each:
-
-| Phase | Name          | What Happens                                                      |
-| ----- | ------------- | ----------------------------------------------------------------- |
-| 1     | Preproduction | Capture game vision, create Game Brief *(optional brainstorming)* |
-| 2     | Design        | Detail mechanics, systems, narrative in GDD                       |
-| 3     | Technical     | Plan engine, architecture, technical decisions                    |
-| 4     | Production    | Build game in sprints, story by story                             |
-
-![BMGD Workflow Overview](./images/workflow-overview.jpg)
-
-*Complete visual flowchart showing all phases, workflows, and agents for game development.*
-
-### Game Development Agents
-
-| Agent                 | When to Use                               |
-| --------------------- | ----------------------------------------- |
-| **Game Designer**     | Brainstorming, Game Brief, GDD, Narrative |
-| **Game Architect**    | Architecture, technical decisions         |
-| **Game Developer**    | Implementation, code reviews              |
-| **Game Scrum Master** | Sprint planning, story management         |
-| **Game QA**           | Test framework, test design, automation   |
-| **Game Solo Dev**     | Quick prototyping, indie development      |
-
-## Installation
-
-If you haven't installed BMad yet:
-
-```bash
-npx bmad-method install
-```
-
-Or add BMGD to an existing installation:
-
-```bash
-npx bmad-method install --add-module bmgd
-```
-
-Verify your installation:
-
-```
-your-project/
-├── _bmad/
-│   ├── bmgd/           # Game development module
-│   │   ├── agents/     # Game-specific agents
-│   │   ├── workflows/  # Game-specific workflows
-│   │   └── config.yaml # Module config
-│   ├── bmm/            # Core method module
-│   └── core/           # Core utilities
-├── _bmad-output/       # Generated artifacts (created later)
-└── .claude/            # IDE configuration (if using Claude Code)
-```
-
-## Step 1: Create Your Game Brief (Preproduction)
-
-Load the **Game Designer** agent in your IDE, wait for the menu, then start with your game concept.
-
-### Optional: Brainstorm First
-
-If you have a vague idea and want help developing it:
-
-```
-Run brainstorm-game
-```
-
-The agent guides you through game-specific ideation techniques to refine your concept.
-
-### Create the Game Brief
-
-```
-Run create-game-brief
-```
-
-The Game Designer walks you through:
-- **Game concept** — Core idea and unique selling points
-- **Design pillars** — The 3-5 principles that guide all decisions
-- **Target market** — Who plays this game?
-- **Fundamentals** — Platform, genre, scope, team size
-
-When complete, you'll have `game-brief.md` in your `_bmad-output/` folder.
-
-:::caution[Fresh Chats]
-Always start a fresh chat for each workflow. This prevents context limitations from causing issues.
-:::
-
-## Step 2: Design Your Game
-
-With your Game Brief complete, detail your game's design.
-
-### Create the GDD
-
-**Start a fresh chat** with the **Game Designer** agent.
-
-```
-Run create-gdd
-```
-
-The agent guides you through mechanics, systems, and game-type-specific sections. BMGD offers 24 game type templates that provide genre-specific structure.
-
-When complete, you'll have `gdd.md` (or sharded into `gdd/` for large documents).
-
-:::note[Narrative Design (Optional)]
-For story-driven games, start a fresh chat and run `narrative` to create a Narrative Design Document covering story, characters, world, and dialogue.
-:::
-
-:::tip[Check Your Status]
-Unsure what's next? Load any agent and run `workflow-status`. It tells you the next recommended workflow.
-:::
-
-## Step 3: Plan Your Architecture
-
-**Start a fresh chat** with the **Game Architect** agent.
-
-```
-Run create-architecture
-```
-
-The architect guides you through:
-- **Engine selection** — Unity, Unreal, Godot, custom, etc.
-- **System design** — Core game systems and how they interact
-- **Technical patterns** — Architecture patterns suited to your game
-- **Structure** — Project organization and conventions
-
-When complete, you'll have `game-architecture.md`.
-
-## Step 4: Build Your Game
-
-Once planning is complete, move to production. **Each workflow should run in a fresh chat.**
-
-### Initialize Sprint Planning
-
-Load the **Game Scrum Master** agent and run `sprint-planning`. This creates `sprint-status.yaml` to track all epics and stories.
-
-### The Build Cycle
-
-For each story, repeat this cycle with fresh chats:
-
-| Step | Agent    | Workflow       | Purpose                            |
-| ---- | -------- | -------------- | ---------------------------------- |
-| 1    | Game SM  | `create-story` | Create story file from epic        |
-| 2    | Game Dev | `dev-story`    | Implement the story                |
-| 3    | Game QA  | `automate`     | Generate tests *(optional)*        |
-| 4    | Game Dev | `code-review`  | Quality validation *(recommended)* |
-
-After completing all stories in an epic, load the **Game SM** and run `retrospective`.
-
-### Quick Prototyping Alternative
-
-For rapid iteration or indie development, load the **Game Solo Dev** agent:
-- `quick-prototype` — Rapid prototyping
-- `quick-dev` — Flexible development without full sprint structure
-
-## What You've Accomplished
-
-You've learned the foundation of building games with BMad:
-
-- Installed the BMGD module
-- Created a Game Brief capturing your vision
-- Detailed your design in a GDD
-- Planned your technical architecture
-- Understood the build cycle for implementation
-
-Your project now has:
-
-```
-your-project/
-├── _bmad/                         # BMad configuration
-├── _bmad-output/
-│   ├── game-brief.md              # Your game vision
-│   ├── gdd.md                     # Game Design Document
-│   ├── narrative-design.md        # Story design (if applicable)
-│   ├── game-architecture.md       # Technical decisions
-│   ├── epics/                     # Epic and story files
-│   └── sprint-status.yaml         # Sprint tracking
-└── ...
-```
-
-## Quick Reference
-
-| Command                | Agent          | Purpose                       |
-| ---------------------- | -------------- | ----------------------------- |
-| `*brainstorm-game`     | Game Designer  | Guided game ideation          |
-| `*create-game-brief`   | Game Designer  | Create Game Brief             |
-| `*create-gdd`          | Game Designer  | Create Game Design Document   |
-| `*narrative`           | Game Designer  | Create Narrative Design       |
-| `*create-architecture` | Game Architect | Create game architecture      |
-| `*sprint-planning`     | Game SM        | Initialize sprint tracking    |
-| `*create-story`        | Game SM        | Create a story file           |
-| `*dev-story`           | Game Dev       | Implement a story             |
-| `*code-review`         | Game Dev       | Review implemented code       |
-| `*workflow-status`     | Any            | Check progress and next steps |
-
-## Common Questions
-
-**Do I need to create all documents?**
-At minimum, create a Game Brief and GDD. Architecture is highly recommended. Narrative Design is only needed for story-driven games.
-
-**Can I use the Game Solo Dev for everything?**
-Yes, for smaller projects or rapid prototyping. For larger games, the specialized agents provide more thorough guidance.
-
-**What game types are supported?**
-BMGD includes 24 game type templates (RPG, platformer, puzzle, strategy, etc.) that provide genre-specific GDD sections.
-
-**Can I change my design later?**
-Yes. Documents are living artifacts—return to update them as your vision evolves. The SM agent has `correct-course` for scope changes.
-
-## Getting Help
-
-- **During workflows** — Agents guide you with questions and explanations
-- **Community** — [Discord](https://discord.gg/gk8jAdXWmj) (#bmad-method-help, #report-bugs-and-issues)
-- **Documentation** — [BMGD Workflow Reference](/docs/reference/workflows/bmgd-workflows.md)
-- **Video tutorials** — [BMad Code YouTube](https://www.youtube.com/@BMadCode)
-
-## Key Takeaways
-
-:::tip[Remember These]
-- **Always use fresh chats** — Load agents in new chats for each workflow
-- **Game Brief first** — It informs everything that follows
-- **Use game type templates** — 24 templates provide genre-specific GDD structure
-- **Documents evolve** — Return to update them as your vision grows
-- **Solo Dev for speed** — Use Game Solo Dev for rapid prototyping
-:::
-
-Ready to start? Load the **Game Designer** agent and run `create-game-brief` to capture your game vision.

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

@@ -0,0 +1,446 @@
+---
+title: "Getting Started with Test Architect"
+description: Learn Test Architect fundamentals by generating and running tests for an existing demo app in 30 minutes
+---
+
+Welcome! **Test Architect (TEA) Lite** is the simplest way to get started with TEA - just use `*automate` to generate tests for existing features. Perfect for beginners who want to learn TEA fundamentals quickly.
+
+## What You'll Build
+
+By the end of this 30-minute tutorial, you'll have:
+- A working Playwright test framework
+- Your first risk-based test plan
+- Passing tests for an existing demo app feature
+
+:::note[Prerequisites]
+- Node.js installed (v18 or later)
+- 30 minutes of focused time
+
+- We'll use TodoMVC (<https://todomvc.com/examples/react/dist/>) as our demo app
+:::
+
+:::tip[Quick Path]
+Load TEA (`*tea`) → scaffold framework (`*framework`) → create test plan (`*test-design`) → generate tests (`*automate`) → run with `npx playwright test`.
+:::
+
+
+## TEA Approaches Explained
+
+Before we start, understand the three ways to use TEA:
+
+- **TEA Lite** (this tutorial): Beginner using just `*automate` to test existing features
+- **TEA Solo**: Using TEA standalone without full BMad Method integration
+- **TEA Integrated**: Full BMad Method with all TEA workflows across phases
+
+This tutorial focuses on **TEA Lite** - the fastest way to see TEA in action.
+
+## Step 0: Setup (2 minutes)
+
+We'll test TodoMVC, a standard demo app used across testing documentation.
+
+**Demo App:** <https://todomvc.com/examples/react/dist/>
+
+No installation needed - TodoMVC runs in your browser. Open the link above and:
+1. Add a few todos (type and press Enter)
+2. Mark some as complete (click checkbox)
+3. Try the "All", "Active", "Completed" filters
+
+You've just explored the features we'll test!
+
+## Step 1: Install BMad and Scaffold Framework (10 minutes)
+
+### Install BMad Method
+
+Install BMad (see installation guide for latest command).
+
+When prompted:
+- **Select modules:** Choose "BMM: BMad Method" (press Space, then Enter)
+- **Project name:** Keep default or enter your project name
+- **Experience level:** Choose "beginner" for this tutorial
+- **Planning artifacts folder:** Keep default
+- **Implementation artifacts folder:** Keep default
+- **Project knowledge folder:** Keep default
+- **Enable TEA Playwright Model Context Protocol (MCP) enhancements?** Choose "No" for now (we'll explore this later)
+- **Using playwright-utils?** Choose "No" for now (we'll explore this later)
+
+BMad is now installed! You'll see a `_bmad/` folder in your project.
+
+### Load TEA Agent
+
+Start a new chat with your AI assistant (Claude, etc.) and type:
+
+```
+*tea
+```
+
+This loads the Test Architect agent. You'll see TEA's menu with available workflows.
+
+### Scaffold Test Framework
+
+In your chat, run:
+
+```
+*framework
+```
+
+TEA will ask you questions:
+
+**Q: What's your tech stack?**
+A: "We're testing a React web application (TodoMVC)"
+
+**Q: Which test framework?**
+A: "Playwright"
+
+**Q: Testing scope?**
+A: "End-to-end (E2E) testing for a web application"
+
+**Q: Continuous integration/continuous deployment (CI/CD) platform?**
+A: "GitHub Actions" (or your preference)
+
+TEA will generate:
+- `tests/` directory with Playwright config
+- `playwright.config.ts` with base configuration
+- Sample test structure
+- `.env.example` for environment variables
+- `.nvmrc` for Node version
+
+**Verify the setup:**
+
+```bash
+npm install
+npx playwright install
+```
+
+You now have a production-ready test framework!
+
+## Step 2: Your First Test Design (5 minutes)
+
+Test design is where TEA shines - risk-based planning before writing tests.
+
+### Run Test Design
+
+In your chat with TEA, run:
+
+```
+*test-design
+```
+
+**Q: System-level or epic-level?**
+A: "Epic-level - I want to test TodoMVC's basic functionality"
+
+**Q: What feature are you testing?**
+A: "TodoMVC's core operations - creating, completing, and deleting todos"
+
+**Q: Any specific risks or concerns?**
+A: "We want to ensure the filter buttons (All, Active, Completed) work correctly"
+
+TEA will analyze and create `test-design-epic-1.md` with:
+
+1. **Risk Assessment**
+   - Probability × Impact scoring
+   - Risk categories (TECH, SEC, PERF, DATA, BUS, OPS)
+   - High-risk areas identified
+
+2. **Test Priorities**
+   - P0: Critical path (creating and displaying todos)
+   - P1: High value (completing todos, filters)
+   - P2: Medium value (deleting todos)
+   - P3: Low value (edge cases)
+
+3. **Coverage Strategy**
+   - E2E tests for user workflows
+   - Which scenarios need testing
+   - Suggested test structure
+
+**Review the test design file** - notice how TEA provides a systematic approach to what needs testing and why.
+
+## Step 3: Generate Tests for Existing Features (5 minutes)
+
+Now the magic happens - TEA generates tests based on your test design.
+
+### Run Automate
+
+In your chat with TEA, run:
+
+```
+*automate
+```
+
+**Q: What are you testing?**
+A: "TodoMVC React app at <https://todomvc.com/examples/react/dist/> - focus on the test design we just created"
+
+**Q: Reference existing docs?**
+A: "Yes, use test-design-epic-1.md"
+
+**Q: Any specific test scenarios?**
+A: "Cover the P0 and P1 scenarios from the test design"
+
+TEA will generate:
+
+**`tests/e2e/todomvc.spec.ts`** with tests like:
+```typescript
+import { test, expect } from '@playwright/test';
+
+test.describe('TodoMVC - Core Functionality', () => {
+  test.beforeEach(async ({ page }) => {
+    await page.goto('https://todomvc.com/examples/react/dist/');
+  });
+
+  test('should create a new todo', async ({ page }) => {
+    // TodoMVC uses a simple input without placeholder or test IDs
+    const todoInput = page.locator('.new-todo');
+    await todoInput.fill('Buy groceries');
+    await todoInput.press('Enter');
+
+    // Verify todo appears in list
+    await expect(page.locator('.todo-list li')).toContainText('Buy groceries');
+  });
+
+  test('should mark todo as complete', async ({ page }) => {
+    // Create a todo
+    const todoInput = page.locator('.new-todo');
+    await todoInput.fill('Complete tutorial');
+    await todoInput.press('Enter');
+
+    // Mark as complete using the toggle checkbox
+    await page.locator('.todo-list li .toggle').click();
+
+    // Verify completed state
+    await expect(page.locator('.todo-list li')).toHaveClass(/completed/);
+  });
+
+  test('should filter todos by status', async ({ page }) => {
+    // Create multiple todos
+    const todoInput = page.locator('.new-todo');
+    await todoInput.fill('Buy groceries');
+    await todoInput.press('Enter');
+    await todoInput.fill('Write tests');
+    await todoInput.press('Enter');
+
+    // Complete the first todo ("Buy groceries")
+    await page.locator('.todo-list li .toggle').first().click();
+
+    // Test Active filter (shows only incomplete todos)
+    await page.locator('.filters a[href="#/active"]').click();
+    await expect(page.locator('.todo-list li')).toHaveCount(1);
+    await expect(page.locator('.todo-list li')).toContainText('Write tests');
+
+    // Test Completed filter (shows only completed todos)
+    await page.locator('.filters a[href="#/completed"]').click();
+    await expect(page.locator('.todo-list li')).toHaveCount(1);
+    await expect(page.locator('.todo-list li')).toContainText('Buy groceries');
+  });
+});
+```
+
+TEA also creates:
+- **`tests/README.md`** - How to run tests, project conventions
+- **Definition of Done summary** - What makes a test "good"
+
+### With Playwright Utils (Optional Enhancement)
+
+If you have `tea_use_playwright_utils: true` in your config, TEA generates tests using production-ready utilities:
+
+**Vanilla Playwright:**
+```typescript
+test('should mark todo as complete', async ({ page, request }) => {
+  // Manual API call
+  const response = await request.post('/api/todos', {
+    data: { title: 'Complete tutorial' }
+  });
+  const todo = await response.json();
+
+  await page.goto('/');
+  await page.locator(`.todo-list li:has-text("${todo.title}") .toggle`).click();
+  await expect(page.locator('.todo-list li')).toHaveClass(/completed/);
+});
+```
+
+**With Playwright Utils:**
+```typescript
+import { test } from '@seontechnologies/playwright-utils/api-request/fixtures';
+import { expect } from '@playwright/test';
+
+test('should mark todo as complete', async ({ page, apiRequest }) => {
+  // Typed API call with cleaner syntax
+  const { status, body: todo } = await apiRequest({
+    method: 'POST',
+    path: '/api/todos',
+    body: { title: 'Complete tutorial' }  
+  });
+
+  expect(status).toBe(201);
+  await page.goto('/');
+  await page.locator(`.todo-list li:has-text("${todo.title}") .toggle`).click();
+  await expect(page.locator('.todo-list li')).toHaveClass(/completed/);
+});
+```
+
+**Benefits:**
+- Type-safe API responses (`{ status, body }`)
+- Automatic retry for 5xx errors
+- Built-in schema validation
+- Cleaner, more maintainable code
+
+See [Integrate Playwright Utils](/docs/how-to/customization/integrate-playwright-utils.md) to enable this.
+
+## Step 4: Run and Validate (5 minutes)
+
+Time to see your tests in action!
+
+### Run the Tests
+
+```bash
+npx playwright test
+```
+
+You should see:
+```
+Running 3 tests using 1 worker
+
+  ✓ tests/e2e/todomvc.spec.ts:7:3 › should create a new todo (2s)
+  ✓ tests/e2e/todomvc.spec.ts:15:3 › should mark todo as complete (2s)
+  ✓ tests/e2e/todomvc.spec.ts:30:3 › should filter todos by status (3s)
+
+  3 passed (7s)
+```
+
+All green! Your tests are passing against the existing TodoMVC app.
+
+### View Test Report
+
+```bash
+npx playwright show-report
+```
+
+Opens a beautiful HTML report showing:
+- Test execution timeline
+- Screenshots (if any failures)
+- Trace viewer for debugging
+
+### What Just Happened?
+
+You used **TEA Lite** to:
+1. Scaffold a production-ready test framework (`*framework`)
+2. Create a risk-based test plan (`*test-design`)
+3. Generate comprehensive tests (`*automate`)
+4. Run tests against an existing application
+
+All in 30 minutes!
+
+## What You Learned
+
+Congratulations! You've completed the TEA Lite tutorial. You learned:
+
+### Quick Reference
+
+| Command        | Purpose                              |
+| -------------- | ------------------------------------ |
+| `*tea`         | Load the TEA agent                   |
+| `*framework`   | Scaffold test infrastructure         |
+| `*test-design` | Risk-based test planning             |
+| `*automate`    | Generate tests for existing features |
+
+### TEA Principles
+- **Risk-based testing** - Depth scales with impact (P0 vs P3)
+- **Test design first** - Plan before generating
+- **Network-first patterns** - Tests wait for actual responses (no hard waits)
+- **Production-ready from day one** - Not toy examples
+
+:::tip[Key Takeaway]
+TEA Lite (just `*automate`) is perfect for beginners learning TEA fundamentals, testing existing applications, quick test coverage expansion, and teams wanting fast results.
+:::
+
+## Understanding ATDD vs Automate
+
+This tutorial used `*automate` to generate tests for **existing features** (tests pass immediately).
+
+**When to use `*automate`:**
+- Feature already exists
+- Want to add test coverage
+- Tests should pass on first run
+
+**When to use `*atdd` (Acceptance Test-Driven Development):**
+- Feature doesn't exist yet (Test-Driven Development workflow)
+- Want failing tests BEFORE implementation
+- Following red → green → refactor cycle
+
+See [How to Run ATDD](/docs/how-to/workflows/run-atdd.md) for the test-drive development (TDD) approach.
+
+## Next Steps
+
+### Level Up Your TEA Skills
+
+**How-To Guides** (task-oriented):
+- [How to Run Test Design](/docs/how-to/workflows/run-test-design.md) - Deep dive into risk assessment
+- [How to Run ATDD](/docs/how-to/workflows/run-atdd.md) - Generate failing tests first (TDD)
+- [How to Set Up CI Pipeline](/docs/how-to/workflows/setup-ci.md) - Automate test execution
+- [How to Review Test Quality](/docs/how-to/workflows/run-test-review.md) - Audit test quality
+
+**Explanation** (understanding-oriented):
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Complete TEA capabilities
+- [Testing as Engineering](/docs/explanation/philosophy/testing-as-engineering.md) - **Why TEA exists** (problem + solution)
+- [Risk-Based Testing](/docs/explanation/tea/risk-based-testing.md) - How risk scoring works
+
+**Reference** (quick lookup):
+- [TEA Command Reference](/docs/reference/tea/commands.md) - All 8 TEA workflows
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Config options
+- [Glossary](/docs/reference/glossary/index.md) - TEA terminology
+
+### Try TEA Solo
+
+Ready for standalone usage without full BMad Method? Use TEA Solo:
+- Run any TEA workflow independently
+- Bring your own requirements
+- Use on non-BMad projects
+
+See [TEA Overview](/docs/explanation/features/tea-overview.md) for engagement models.
+
+### Go Full TEA Integrated
+
+Want the complete quality operating model? Try TEA Integrated with BMad Method:
+- Phase 2: Planning with non-functional requirements (NFR) assessment
+- Phase 3: Architecture testability review
+- Phase 4: Per-epic test design → ATDD → automate
+- Release Gate: Coverage traceability and gate decisions
+
+See [BMad Method Documentation](/) for the full workflow.
+
+## Common Questions
+
+- [Why can't my tests find elements?](#why-cant-my-tests-find-elements)
+- [How do I fix network timeouts?](#how-do-i-fix-network-timeouts)
+
+### Why can't my tests find elements?
+
+TodoMVC doesn't use test IDs or accessible roles consistently. The selectors in this tutorial use CSS classes that match TodoMVC's actual structure:
+
+```typescript
+// TodoMVC uses these CSS classes:
+page.locator('.new-todo')      // Input field
+page.locator('.todo-list li')  // Todo items
+page.locator('.toggle')        // Checkbox
+
+// If testing your own app, prefer accessible selectors:
+page.getByRole('textbox')
+page.getByRole('listitem')
+page.getByRole('checkbox')
+```
+
+In production code, use accessible selectors (`getByRole`, `getByLabel`, `getByText`) for better resilience. TodoMVC is used here for learning, not as a selector best practice example.
+
+### How do I fix network timeouts?
+
+Increase timeout in `playwright.config.ts`:
+
+```typescript
+use: {
+  timeout: 30000, // 30 seconds
+}
+```
+
+## Getting Help
+
+- **Documentation:** <https://docs.bmad-method.org>
+- **GitHub Issues:** <https://github.com/bmad-code-org/bmad-method/issues>
+- **Discord:** Join the BMAD community

package-lock.json

@@ -9,6 +9,7 @@
       "version": "6.0.0-alpha.23",
       "license": "MIT",
       "dependencies": {
+        "@clack/prompts": "^0.11.0",
         "@kayvan/markdown-tree-parser": "^1.6.1",
         "boxen": "^5.1.2",
         "chalk": "^4.1.2",
@@ -19,7 +20,6 @@
         "fs-extra": "^11.3.0",
         "glob": "^11.0.3",
         "ignore": "^7.0.5",
-        "inquirer": "^9.3.8",
         "js-yaml": "^4.1.0",
         "ora": "^5.4.1",
         "semver": "^7.6.3",
@@ -47,7 +47,7 @@
         "jest": "^30.0.4",
         "lint-staged": "^16.1.1",
         "markdownlint-cli2": "^0.19.1",
-        "prettier": "^3.5.3",
+        "prettier": "^3.7.4",
         "prettier-plugin-packagejson": "^2.5.19",
         "sharp": "^0.33.5",
         "yaml-eslint-parser": "^1.2.3",
@@ -755,6 +755,27 @@
         "node": ">=18"
       }
     },
+    "node_modules/@clack/core": {
+      "version": "0.5.0",
+      "resolved": "https://registry.npmjs.org/@clack/core/-/core-0.5.0.tgz",
+      "integrity": "sha512-p3y0FIOwaYRUPRcMO7+dlmLh8PSRcrjuTndsiA0WAFbWES0mLZlrjVoBRZ9DzkPFJZG6KGkJmoEAY0ZcVWTkow==",
+      "license": "MIT",
+      "dependencies": {
+        "picocolors": "^1.0.0",
+        "sisteransi": "^1.0.5"
+      }
+    },
+    "node_modules/@clack/prompts": {
+      "version": "0.11.0",
+      "resolved": "https://registry.npmjs.org/@clack/prompts/-/prompts-0.11.0.tgz",
+      "integrity": "sha512-pMN5FcrEw9hUkZA4f+zLlzivQSeQf5dRGJjSUbvVYDLvpKCdQx5OaknvKzgbtXOizhP+SJJJjqEbOe55uKKfAw==",
+      "license": "MIT",
+      "dependencies": {
+        "@clack/core": "0.5.0",
+        "picocolors": "^1.0.0",
+        "sisteransi": "^1.0.5"
+      }
+    },
     "node_modules/@colors/colors": {
       "version": "1.5.0",
       "resolved": "https://registry.npmjs.org/@colors/colors/-/colors-1.5.0.tgz",
@@ -1997,36 +2018,6 @@
         "url": "https://opencollective.com/libvips"
       }
     },
-    "node_modules/@inquirer/external-editor": {
-      "version": "1.0.3",
-      "resolved": "https://registry.npmjs.org/@inquirer/external-editor/-/external-editor-1.0.3.tgz",
-      "integrity": "sha512-RWbSrDiYmO4LbejWY7ttpxczuwQyZLBUyygsA9Nsv95hpzUWwnNTVQmAq3xuh7vNwCp07UTmE5i11XAEExx4RA==",
-      "license": "MIT",
-      "dependencies": {
-        "chardet": "^2.1.1",
-        "iconv-lite": "^0.7.0"
-      },
-      "engines": {
-        "node": ">=18"
-      },
-      "peerDependencies": {
-        "@types/node": ">=18"
-      },
-      "peerDependenciesMeta": {
-        "@types/node": {
-          "optional": true
-        }
-      }
-    },
-    "node_modules/@inquirer/figures": {
-      "version": "1.0.15",
-      "resolved": "https://registry.npmjs.org/@inquirer/figures/-/figures-1.0.15.tgz",
-      "integrity": "sha512-t2IEY+unGHOzAaVM5Xx6DEWKeXlDDcNPeDyUpsRc6CUhBfU3VQOEl+Vssh7VNp1dR8MdUJBWhuObjXCsVpjN5g==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=18"
-      }
-    },
     "node_modules/@isaacs/balanced-match": {
       "version": "4.0.1",
       "resolved": "https://registry.npmjs.org/@isaacs/balanced-match/-/balanced-match-4.0.1.tgz",
@@ -3640,7 +3631,7 @@
       "version": "25.0.3",
       "resolved": "https://registry.npmjs.org/@types/node/-/node-25.0.3.tgz",
       "integrity": "sha512-W609buLVRVmeW693xKfzHeIV6nJGGz98uCPfeXI1ELMLXVeKYZ9m15fAMSaUPBHYLGFsVRcMmSCksQOrZV9BYA==",
-      "devOptional": true,
+      "dev": true,
       "license": "MIT",
       "dependencies": {
         "undici-types": "~7.16.0"
@@ -4028,6 +4019,7 @@
       "version": "4.3.2",
       "resolved": "https://registry.npmjs.org/ansi-escapes/-/ansi-escapes-4.3.2.tgz",
       "integrity": "sha512-gKXj5ALrKWQLsYG9jlTRmR/xKluxHV+Z9QEwNIgCfM1/uwPMCuzVVnh5mwTd+OuBZcwSIMbqssNWRm1lE51QaQ==",
+      "dev": true,
       "license": "MIT",
       "dependencies": {
         "type-fest": "^0.21.3"
@@ -4043,6 +4035,7 @@
       "version": "0.21.3",
       "resolved": "https://registry.npmjs.org/type-fest/-/type-fest-0.21.3.tgz",
       "integrity": "sha512-t0rzBq87m3fVcduHDUFhKmyyX+9eo6WQjZvf51Ea/M0Q7+T374Jp1aUiyUl0GKxp8M/OETVHSDvmkyPgvX+X2w==",
+      "dev": true,
       "license": "(MIT OR CC0-1.0)",
       "engines": {
         "node": ">=10"
@@ -5596,12 +5589,6 @@
         "url": "https://github.com/sponsors/wooorm"
       }
     },
-    "node_modules/chardet": {
-      "version": "2.1.1",
-      "resolved": "https://registry.npmjs.org/chardet/-/chardet-2.1.1.tgz",
-      "integrity": "sha512-PsezH1rqdV9VvyNhxxOW32/d75r01NY7TQCmOqomRo15ZSOKbpTFVsfjghxo6JloQUCGnH4k1LGu0R4yCLlWQQ==",
-      "license": "MIT"
-    },
     "node_modules/chokidar": {
       "version": "4.0.3",
       "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-4.0.3.tgz",
@@ -5782,15 +5769,6 @@
         "url": "https://github.com/chalk/strip-ansi?sponsor=1"
       }
     },
-    "node_modules/cli-width": {
-      "version": "4.1.0",
-      "resolved": "https://registry.npmjs.org/cli-width/-/cli-width-4.1.0.tgz",
-      "integrity": "sha512-ouuZd4/dm2Sw5Gmqy6bGyNNNe1qt9RpmxveLSO7KcgsTnU7RXfsw+/bukWGo1abgBiMAic068rclZsO4IWmmxQ==",
-      "license": "ISC",
-      "engines": {
-        "node": ">= 12"
-      }
-    },
     "node_modules/cliui": {
       "version": "8.0.1",
       "resolved": "https://registry.npmjs.org/cliui/-/cliui-8.0.1.tgz",
@@ -8263,22 +8241,6 @@
         "@babel/runtime": "^7.23.2"
       }
     },
-    "node_modules/iconv-lite": {
-      "version": "0.7.1",
-      "resolved": "https://registry.npmjs.org/iconv-lite/-/iconv-lite-0.7.1.tgz",
-      "integrity": "sha512-2Tth85cXwGFHfvRgZWszZSvdo+0Xsqmw8k8ZwxScfcBneNUraK+dxRxRm24nszx80Y0TVio8kKLt5sLE7ZCLlw==",
-      "license": "MIT",
-      "dependencies": {
-        "safer-buffer": ">= 2.1.2 < 3.0.0"
-      },
-      "engines": {
-        "node": ">=0.10.0"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/express"
-      }
-    },
     "node_modules/ieee754": {
       "version": "1.2.1",
       "resolved": "https://registry.npmjs.org/ieee754/-/ieee754-1.2.1.tgz",
@@ -8414,43 +8376,6 @@
       "dev": true,
       "license": "MIT"
     },
-    "node_modules/inquirer": {
-      "version": "9.3.8",
-      "resolved": "https://registry.npmjs.org/inquirer/-/inquirer-9.3.8.tgz",
-      "integrity": "sha512-pFGGdaHrmRKMh4WoDDSowddgjT1Vkl90atobmTeSmcPGdYiwikch/m/Ef5wRaiamHejtw0cUUMMerzDUXCci2w==",
-      "license": "MIT",
-      "dependencies": {
-        "@inquirer/external-editor": "^1.0.2",
-        "@inquirer/figures": "^1.0.3",
-        "ansi-escapes": "^4.3.2",
-        "cli-width": "^4.1.0",
-        "mute-stream": "1.0.0",
-        "ora": "^5.4.1",
-        "run-async": "^3.0.0",
-        "rxjs": "^7.8.1",
-        "string-width": "^4.2.3",
-        "strip-ansi": "^6.0.1",
-        "wrap-ansi": "^6.2.0",
-        "yoctocolors-cjs": "^2.1.2"
-      },
-      "engines": {
-        "node": ">=18"
-      }
-    },
-    "node_modules/inquirer/node_modules/wrap-ansi": {
-      "version": "6.2.0",
-      "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-6.2.0.tgz",
-      "integrity": "sha512-r6lPcBGxZXlIcymEu7InxDMhdW0KDxpLgoFLcguasxCaJ/SOIZwINatK9KY/tf+ZrlywOKU0UDj3ATXUBfxJXA==",
-      "license": "MIT",
-      "dependencies": {
-        "ansi-styles": "^4.0.0",
-        "string-width": "^4.1.0",
-        "strip-ansi": "^6.0.0"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
     "node_modules/iron-webcrypto": {
       "version": "1.2.1",
       "resolved": "https://registry.npmjs.org/iron-webcrypto/-/iron-webcrypto-1.2.1.tgz",
@@ -11569,15 +11494,6 @@
       "integrity": "sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==",
       "license": "MIT"
     },
-    "node_modules/mute-stream": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/mute-stream/-/mute-stream-1.0.0.tgz",
-      "integrity": "sha512-avsJQhyd+680gKXyG/sQc0nXaC6rBkPOfyHYcFb9+hdkqQkR9bdnkJ0AMZhke0oesPqIO+mFFJ+IdBc7mst4IA==",
-      "license": "ISC",
-      "engines": {
-        "node": "^14.17.0 || ^16.13.0 || >=18.0.0"
-      }
-    },
     "node_modules/nano-spawn": {
       "version": "2.0.0",
       "resolved": "https://registry.npmjs.org/nano-spawn/-/nano-spawn-2.0.0.tgz",
@@ -12233,7 +12149,6 @@
       "version": "1.1.1",
       "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.1.1.tgz",
       "integrity": "sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==",
-      "dev": true,
       "license": "ISC"
     },
     "node_modules/picomatch": {
@@ -13300,15 +13215,6 @@
         "fsevents": "~2.3.2"
       }
     },
-    "node_modules/run-async": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/run-async/-/run-async-3.0.0.tgz",
-      "integrity": "sha512-540WwVDOMxA6dN6We19EcT9sc3hkXPw5mzRNGM3FkdN/vtE9NFvj5lFAPNwUDmJjXidm3v7TC1cTE7t17Ulm1Q==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=0.12.0"
-      }
-    },
     "node_modules/run-parallel": {
       "version": "1.2.0",
       "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.2.0.tgz",
@@ -13333,15 +13239,6 @@
         "queue-microtask": "^1.2.2"
       }
     },
-    "node_modules/rxjs": {
-      "version": "7.8.2",
-      "resolved": "https://registry.npmjs.org/rxjs/-/rxjs-7.8.2.tgz",
-      "integrity": "sha512-dhKf903U/PQZY6boNNtAGdWbG85WAbjT/1xYoZIC7FAY0yWapOBQVsVrDl58W86//e1VpMNBtRV4MaXfdMySFA==",
-      "license": "Apache-2.0",
-      "dependencies": {
-        "tslib": "^2.1.0"
-      }
-    },
     "node_modules/safe-buffer": {
       "version": "5.2.1",
       "resolved": "https://registry.npmjs.org/safe-buffer/-/safe-buffer-5.2.1.tgz",
@@ -13362,12 +13259,6 @@
       ],
       "license": "MIT"
     },
-    "node_modules/safer-buffer": {
-      "version": "2.1.2",
-      "resolved": "https://registry.npmjs.org/safer-buffer/-/safer-buffer-2.1.2.tgz",
-      "integrity": "sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==",
-      "license": "MIT"
-    },
     "node_modules/sax": {
       "version": "1.4.3",
       "resolved": "https://registry.npmjs.org/sax/-/sax-1.4.3.tgz",
@@ -13504,7 +13395,6 @@
       "version": "1.0.5",
       "resolved": "https://registry.npmjs.org/sisteransi/-/sisteransi-1.0.5.tgz",
       "integrity": "sha512-bLGGlR1QxBcynn2d5YmDX4MGjlZvy2MRBDRNHLJ8VI6l6+9FUiyTFNJ0IveOSP0bcXgVDPRcfGqA0pjaqUpfVg==",
-      "dev": true,
       "license": "MIT"
     },
     "node_modules/sitemap": {
@@ -14241,6 +14131,7 @@
       "version": "2.8.1",
       "resolved": "https://registry.npmjs.org/tslib/-/tslib-2.8.1.tgz",
       "integrity": "sha512-oJFu94HQb+KVduSUQL7wnpmqnfmLsOA/nAh6b6EH0wCEoK0/mPeXU6c3wKDV83MkOuHPRHtSXKKU99IBazS/2w==",
+      "dev": true,
       "license": "0BSD"
     },
     "node_modules/type-check": {
@@ -14325,7 +14216,7 @@
       "version": "7.16.0",
       "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-7.16.0.tgz",
       "integrity": "sha512-Zz+aZWSj8LE6zoxD+xrjh4VfkIG8Ya6LvYkZqtUQGJPZjYl53ypCaUwWqo7eI0x66KBGeRo+mlBEkMSeSZ38Nw==",
-      "devOptional": true,
+      "dev": true,
       "license": "MIT"
     },
     "node_modules/unicode-properties": {
@@ -15258,18 +15149,6 @@
         "url": "https://github.com/sponsors/sindresorhus"
       }
     },
-    "node_modules/yoctocolors-cjs": {
-      "version": "2.1.3",
-      "resolved": "https://registry.npmjs.org/yoctocolors-cjs/-/yoctocolors-cjs-2.1.3.tgz",
-      "integrity": "sha512-U/PBtDf35ff0D8X8D0jfdzHYEPFxAI7jJlxZXwCSez5M3190m+QobIfh+sWDWSHMCWWJN2AWamkegn6vr6YBTw==",
-      "license": "MIT",
-      "engines": {
-        "node": ">=18"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
-      }
-    },
     "node_modules/zip-stream": {
       "version": "6.0.1",
       "resolved": "https://registry.npmjs.org/zip-stream/-/zip-stream-6.0.1.tgz",

package.json

@@ -34,6 +34,7 @@
     "flatten": "node tools/flattener/main.js",
     "format:check": "prettier --check \"**/*.{js,cjs,mjs,json,yaml}\"",
     "format:fix": "prettier --write \"**/*.{js,cjs,mjs,json,yaml}\"",
+    "format:fix:staged": "prettier --write",
     "install:bmad": "node tools/cli/bmad-cli.js install",
     "lint": "eslint . --ext .js,.cjs,.mjs,.yaml --max-warnings=0",
     "lint:fix": "eslint . --ext .js,.cjs,.mjs,.yaml --fix",
@@ -53,20 +54,21 @@
   "lint-staged": {
     "*.{js,cjs,mjs}": [
       "npm run lint:fix",
-      "npm run format:fix"
+      "npm run format:fix:staged"
     ],
     "*.yaml": [
       "eslint --fix",
-      "npm run format:fix"
+      "npm run format:fix:staged"
     ],
     "*.json": [
-      "npm run format:fix"
+      "npm run format:fix:staged"
     ],
     "*.md": [
       "markdownlint-cli2"
     ]
   },
   "dependencies": {
+    "@clack/prompts": "^0.11.0",
     "@kayvan/markdown-tree-parser": "^1.6.1",
     "boxen": "^5.1.2",
     "chalk": "^4.1.2",
@@ -77,7 +79,6 @@
     "fs-extra": "^11.3.0",
     "glob": "^11.0.3",
     "ignore": "^7.0.5",
-    "inquirer": "^9.3.8",
     "js-yaml": "^4.1.0",
     "ora": "^5.4.1",
     "semver": "^7.6.3",
@@ -101,7 +102,7 @@
     "jest": "^30.0.4",
     "lint-staged": "^16.1.1",
     "markdownlint-cli2": "^0.19.1",
-    "prettier": "^3.5.3",
+    "prettier": "^3.7.4",
     "prettier-plugin-packagejson": "^2.5.19",
     "sharp": "^0.33.5",
     "yaml-eslint-parser": "^1.2.3",