bmad-method 6.0.0-alpha.12 → 6.0.0-alpha.14

package/src/modules/bmm/docs/quick-flow-solo-dev.md

@@ -0,0 +1,337 @@
+# Quick Flow Solo Dev Agent (Barry)
+
+**Agent ID:** `.bmad/bmm/agents/quick-flow-solo-dev.md`
+**Icon:** 🚀
+**Module:** BMM
+
+---
+
+## Overview
+
+Barry is the elite solo developer who lives and breathes the BMAD Quick Flow workflow. He takes projects from concept to deployment with ruthless efficiency - no handoffs, no delays, just pure focused development. Barry architects specs, writes the code, and ships features faster than entire teams. When you need it done right and done now, Barry's your dev.
+
+### Agent Persona
+
+**Name:** Barry
+**Title:** Quick Flow Solo Dev
+
+**Identity:** Barry is an elite developer who thrives on autonomous execution. He lives and breathes the BMAD Quick Flow workflow, taking projects from concept to deployment with ruthless efficiency. No handoffs, no delays - just pure, focused development. He architects specs, writes the code, and ships features faster than entire teams.
+
+**Communication Style:** Direct, confident, and implementation-focused. Uses tech slang and gets straight to the point. No fluff, just results. Every response moves the project forward.
+
+**Core Principles:**
+
+- Planning and execution are two sides of the same coin
+- Quick Flow is my religion
+- Specs are for building, not bureaucracy
+- Code that ships is better than perfect code that doesn't
+- 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.
+
+### 1. **create-tech-spec**
+
+- **Workflow:** `.bmad/bmm/workflows/bmad-quick-flow/create-tech-spec/workflow.yaml`
+- **Description:** Architect a technical spec with implementation-ready stories
+- **Use when:** You need to transform requirements into a buildable spec
+
+### 2. **quick-dev**
+
+- **Workflow:** `.bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.yaml`
+- **Description:** Ship features from spec or direct instructions - no handoffs
+- **Use when:** You're ready to ship code based on a spec or clear instructions
+
+### 3. **code-review**
+
+- **Workflow:** `.bmad/bmm/workflows/4-implementation/code-review/workflow.yaml`
+- **Description:** Review code for quality, patterns, and acceptance criteria
+- **Use when:** You need to validate implementation quality
+
+### 4. **party-mode**
+
+- **Workflow:** `.bmad/core/workflows/party-mode/workflow.yaml`
+- **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
+
+1. **Quick Flow Development** - Small to medium features that need rapid delivery
+2. **Technical Specification Creation** - When you need detailed implementation plans
+3. **Direct Development** - When requirements are clear and you want to skip extensive planning
+4. **Code Reviews** - When you need senior-level technical validation
+5. **Performance-Critical Features** - When optimization and scalability are paramount
+
+### Project Types
+
+- **Greenfield Projects** - New features or components
+- **Brownfield Modifications** - Enhancements to existing codebases
+- **Bug Fixes** - Complex issues requiring deep technical understanding
+- **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:
+
+```mermaid
+flowchart LR
+    A[Requirements] --> B[create-tech-spec]
+    B --> C[Tech Spec]
+    C --> D[quick-dev]
+    D --> E[Implementation]
+    E --> F{Code Review?}
+    F -->|Yes| G[code-review]
+    F -->|No| H[Complete]
+    G --> H[Complete]
+
+    style A fill:#e1f5fe
+    style B fill:#f3e5f5
+    style C fill:#e8f5e9
+    style D fill:#fff3e0
+    style E fill:#fce4ec
+    style G fill:#f1f8e9
+    style H fill:#e0f2f1
+```
+
+### Step 1: Technical Specification (`create-tech-spec`)
+
+**Goal:** Transform user requirements into implementation-ready technical specifications
+
+**Process:**
+
+1. **Problem Understanding** - Clarify requirements, scope, and constraints
+2. **Code Investigation** - Analyze existing patterns and dependencies (if applicable)
+3. **Specification Generation** - Create comprehensive tech spec with:
+   - Problem statement and solution overview
+   - Development context and patterns
+   - Implementation tasks with acceptance criteria
+   - Technical decisions and dependencies
+4. **Review and Finalize** - Validate spec captures user intent
+
+**Output:** `tech-spec-{slug}.md` saved to sprint artifacts
+
+**Best Practices:**
+
+- Include ALL context a fresh dev agent needs
+- Be specific about files, patterns, and conventions
+- Define clear acceptance criteria using Given/When/Then format
+- Document technical decisions and trade-offs
+
+### Step 2: Development (`quick-dev`)
+
+**Goal:** Execute implementation based on tech spec or direct instructions
+
+**Two Modes:**
+
+**Mode A: Tech-Spec Driven**
+
+- Load existing tech spec
+- Extract tasks, context, and acceptance criteria
+- Execute all tasks continuously without stopping
+- Respect project context and existing patterns
+
+**Mode B: Direct Instructions**
+
+- Accept direct development commands
+- Offer optional planning step
+- Execute with minimal friction
+
+**Process:**
+
+1. **Load Project Context** - Understand patterns and conventions
+2. **Execute Implementation** - Work through all tasks:
+   - Load relevant files and context
+   - Implement following established patterns
+   - Write and run tests
+   - Handle errors appropriately
+3. **Verify Completion** - Ensure all tasks complete, tests passing, AC satisfied
+
+### Step 3: Code Review (`code-review`) - Optional
+
+**Goal:** Senior developer review of implemented code
+
+**When to Use:**
+
+- Critical production features
+- Complex architectural changes
+- Performance-sensitive implementations
+- Team development scenarios
+- Learning and knowledge transfer
+
+**Review Focus:**
+
+- Code quality and patterns
+- Acceptance criteria compliance
+- Performance and scalability
+- Security considerations
+- Maintainability and documentation
+
+---
+
+## Collaboration with Other Agents
+
+### Natural Partnerships
+
+- **Tech Writer** - For documentation and API specs when I need it
+- **Architect** - For complex system design decisions beyond Quick Flow scope
+- **Dev** - For implementation pair programming (rarely needed)
+- **QA** - For test strategy and quality gates on critical features
+- **UX Designer** - For user experience considerations
+
+### Party Mode Composition
+
+In party mode, Barry often acts as:
+
+- **Solo Tech Lead** - Guiding architectural decisions
+- **Implementation Expert** - Providing coding insights
+- **Performance Optimizer** - Ensuring scalable solutions
+- **Code Review Authority** - Validating technical approaches
+
+---
+
+## Tips for Working with Barry
+
+### For Best Results
+
+1. **Be Specific** - Provide clear requirements and constraints
+2. **Share Context** - Include relevant files and patterns
+3. **Define Success** - Clear acceptance criteria lead to better outcomes
+4. **Trust the Process** - The 3-step flow is optimized for speed and quality
+5. **Leverage Expertise** - I'll give you optimization and architectural insights automatically
+
+### Communication Patterns
+
+- **Git Commit Style** - "feat: Add user authentication with OAuth 2.0"
+- **RFC Style** - "Proposing microservice architecture for scalability"
+- **Direct Questions** - "Actually, have you considered the race condition?"
+- **Technical Trade-offs** - "We could optimize for speed over memory here"
+
+### Avoid These Common Mistakes
+
+1. **Vague Requirements** - Leads to unnecessary back-and-forth
+2. **Ignoring Patterns** - Causes technical debt and inconsistencies
+3. **Skipping Code Review** - Missed opportunities for quality improvement
+4. **Over-planning** - I excel at rapid, pragmatic development
+5. **Not Using Party Mode** - Missing collaborative insights for complex problems
+
+---
+
+## Example Workflow
+
+```bash
+# Start with Barry
+/bmad:bmm:agents:quick-flow-solo-dev
+
+# Create a tech spec
+> create-tech-spec
+
+# Quick implementation
+> quick-dev tech-spec-auth.md
+
+# Optional code review
+> code-review
+```
+
+### Sample Tech Spec Structure
+
+```markdown
+# Tech-Spec: User Authentication System
+
+**Created:** 2025-01-15
+**Status:** Ready for Development
+
+## Overview
+
+### Problem Statement
+
+Users cannot securely access the application, and we need role-based permissions for enterprise features.
+
+### Solution
+
+Implement OAuth 2.0 authentication with JWT tokens and role-based access control (RBAC).
+
+### Scope (In/Out)
+
+**In:** Login, logout, password reset, role management
+**Out:** Social login, SSO, multi-factor authentication (Phase 2)
+
+## Context for Development
+
+### Codebase Patterns
+
+- Use existing auth middleware pattern in `src/middleware/auth.js`
+- Follow service layer pattern from `src/services/`
+- JWT secrets managed via environment variables
+
+### Files to Reference
+
+- `src/middleware/auth.js` - Authentication middleware
+- `src/models/User.js` - User data model
+- `config/database.js` - Database connection
+
+### Technical Decisions
+
+- JWT tokens over sessions for API scalability
+- bcrypt for password hashing
+- Role-based permissions stored in database
+
+## Implementation Plan
+
+### Tasks
+
+- [ ] Create authentication service
+- [ ] Implement login/logout endpoints
+- [ ] Add JWT middleware
+- [ ] Create role-based permissions
+- [ ] Write comprehensive tests
+
+### Acceptance Criteria
+
+- [ ] Given valid credentials, when user logs in, then receive JWT token
+- [ ] Given invalid token, when accessing protected route, then return 401
+- [ ] Given admin role, when accessing admin endpoint, then allow access
+```
+
+---
+
+## Related Documentation
+
+- **[Quick Start Guide](./quick-start.md)** - Getting started with BMM
+- **[Agents Guide](./agents-guide.md)** - Complete agent reference
+- **[Scale Adaptive System](./scale-adaptive-system.md)** - Understanding development tracks
+- **[Workflow Implementation](./workflows-implementation.md)** - Implementation workflows
+- **[Party Mode](./party-mode.md)** - Multi-agent collaboration
+
+---
+
+## Frequently Asked Questions
+
+**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.
+
+**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.
+
+**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.
+
+**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.
+
+**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.
+
+---
+
+**Ready to ship some code?** → Start with `/bmad:bmm:agents:quick-flow-solo-dev`

package/src/modules/bmm/docs/quick-spec-flow.md

@@ -60,10 +60,10 @@ flowchart TD
     STORIES --> IMPL
     IMPL --> DONE
 
-    style START fill:#bfb,stroke:#333,stroke-width:2px,color:#000
-    style OPTIONAL fill:#ffb,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5,color:#000
-    style IMPL fill:#bbf,stroke:#333,stroke-width:2px,color:#000
-    style DONE fill:#f9f,stroke:#333,stroke-width:3px,color:#000
+    style START fill:#bfb,stroke:#333,stroke-width:2px
+    style OPTIONAL fill:#ffb,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
+    style IMPL fill:#bbf,stroke:#333,stroke-width:2px
+    style DONE fill:#f9f,stroke:#333,stroke-width:3px
 ```
 
 ---
@@ -645,7 +645,7 @@ Quick Spec Flow is your **fast path from idea to implementation** for:
 - **Try it now:** Load PM agent and describe a small change
 - **Learn more:** See the [BMM Workflow Guides](./README.md#-workflow-guides) for comprehensive workflow documentation
 - **Need help deciding?** Run `workflow-init` to get a recommendation
-- **Have questions?** Join us on Discord: https://discord.gg/gk8jAdXWmj
+- **Have questions?** Join us on Discord: <https://discord.gg/gk8jAdXWmj>
 
 ---
 

package/src/modules/bmm/docs/quick-start.md

@@ -200,35 +200,21 @@ Once planning and architecture are complete, you'll move to Phase 4. **Important
 3. Tell the agent: "Run sprint-planning"
 4. This creates your `sprint-status.yaml` file that tracks all epics and stories
 
-#### 3.2 Create Epic Context (Optional but Recommended)
-
-1. **Start a new chat** with the **SM agent**
-2. Wait for the menu
-3. Tell the agent: "Run epic-tech-context"
-4. This creates technical context for the current epic before drafting stories
-
-#### 3.3 Draft Your First Story
+#### 3.2 Draft Your First Story
 
 1. **Start a new chat** with the **SM agent**
 2. Wait for the menu
 3. Tell the agent: "Run create-story"
 4. This drafts the story file from the epic
 
-#### 3.4 Add Story Context (Optional but Recommended)
-
-1. **Start a new chat** with the **SM agent**
-2. Wait for the menu
-3. Tell the agent: "Run story-context"
-4. This creates implementation-specific technical context for the story
-
-#### 3.5 Implement the Story
+#### 3.3 Implement the Story
 
 1. **Start a new chat** with the **DEV agent**
 2. Wait for the menu
 3. Tell the agent: "Run dev-story"
 4. The DEV agent will implement the story and update the sprint status
 
-#### 3.6 Review the Code (Optional but Recommended)
+#### 3.4 Review the Code (Optional but Recommended)
 
 1. **Start a new chat** with the **DEV agent**
 2. Wait for the menu
@@ -240,9 +226,8 @@ Once planning and architecture are complete, you'll move to Phase 4. **Important
 For each subsequent story, repeat the cycle using **fresh chats** for each workflow:
 
 1. **New chat** → SM agent → "Run create-story"
-2. **New chat** → SM agent → "Run story-context"
-3. **New chat** → DEV agent → "Run dev-story"
-4. **New chat** → DEV agent → "Run code-review" (optional but recommended)
+2. **New chat** → DEV agent → "Run dev-story"
+3. **New chat** → DEV agent → "Run code-review" (optional but recommended)
 
 After completing all stories in an epic:
 
@@ -328,11 +313,10 @@ flowchart LR
         direction TB
         D1[Per Epic:<br/>epic context]
         D2[Per Story:<br/>create-story]
-        D3[story-context]
-        D4[dev-story]
-        D5[code-review]
-        D6[SM, DEV]
-        D1 ~~~ D2 ~~~ D3 ~~~ D4 ~~~ D5 ~~~ D6
+        D3[dev-story]
+        D4[code-review]
+        D5[SM, DEV]
+        D1 ~~~ D2 ~~~ D3 ~~~ D4 ~~~ D5
     end
 
     P1 --> P2

package/src/modules/bmm/docs/scale-adaptive-system.md

@@ -32,11 +32,11 @@ BMad Method adapts to three distinct planning tracks:
 
 ### Three Tracks at a Glance
 
-| Track                 | Planning Depth        | Time Investment | Best For                                   |
-| --------------------- | --------------------- | --------------- | ------------------------------------------ |
-| **Quick Flow**        | Tech-spec only        | Hours to 1 day  | Simple features, bug fixes, clear scope    |
-| **BMad Method**       | PRD + Arch + UX       | 1-3 days        | Products, platforms, complex features      |
-| **Enterprise Method** | Method + Test/Sec/Ops | 3-7 days        | Enterprise needs, compliance, multi-tenant |
+| Track                 | Planning Depth        | Best For                                   |
+| --------------------- | --------------------- | ------------------------------------------ |
+| **Quick Flow**        | Tech-spec only        | Simple features, bug fixes, clear scope    |
+| **BMad Method**       | PRD + Arch + UX       | Products, platforms, complex features      |
+| **Enterprise Method** | Method + Test/Sec/Ops | Enterprise needs, compliance, multi-tenant |
 
 ### Decision Tree
 

package/src/modules/bmm/docs/test-architecture.md

@@ -88,9 +88,9 @@ 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 0/1:
+**Phase Numbering Note:** BMad uses a 4-phase methodology with optional Phase 1 and documentation prerequisite:
 
-- **Phase 0** (Optional): Documentation (brownfield prerequisite - `*document-project`)
+- **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` → `*create-epics-and-stories` → TEA: `*framework`, `*ci` → `*implementation-readiness`)
@@ -98,7 +98,7 @@ graph TB
 
 **TEA workflows:** `*framework` and `*ci` run once in Phase 3 after architecture. `*test-design` runs per-epic in Phase 4. Output: `test-design-epic-N.md`.
 
-Quick Flow track skips Phases 0, 1, and 3. BMad Method and Enterprise use all phases based on project needs.
+Quick Flow track skips Phase 1 and 3. BMad Method and Enterprise use all phases based on project needs.
 
 ### Why TEA is Different from Other BMM Agents
 
@@ -138,12 +138,12 @@ Epic/Release Gate → TEA: *nfr-assess, *trace Phase 2 (release decision)
 **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** | \*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                              |
 
 **Note**: `*trace` is a two-phase workflow: Phase 1 (traceability) + Phase 2 (gate decision). This reduces cognitive load while maintaining natural workflow.
 
@@ -167,13 +167,35 @@ src/modules/bmm/
 
 TEA uniquely requires:
 
-- **Extensive domain knowledge**: 21 fragments, 12,821 lines covering test patterns, CI/CD, fixtures, quality practices, healing strategies
+- **Extensive domain knowledge**: 32 fragments covering test patterns, CI/CD, fixtures, quality practices, healing strategies, and optional playwright-utils integration
 - **Centralized reference system**: `tea-index.csv` for on-demand fragment loading during workflow execution
 - **Cross-cutting concerns**: Domain-specific testing patterns (vs project-specific artifacts like PRDs/stories)
-- **Optional MCP integration**: Healing, exploratory, and verification modes for enhanced testing capabilities
+- **Optional integrations**: MCP capabilities (healing, exploratory, verification) and playwright-utils support
 
 This architecture enables TEA to maintain consistent, production-ready testing patterns across all BMad projects while operating across multiple development phases.
 
+### Playwright Utils Integration
+
+TEA optionally integrates with `@seontechnologies/playwright-utils`, an open-source library providing fixture-based utilities for Playwright tests.
+
+**Installation:**
+
+```bash
+npm install -D @seontechnologies/playwright-utils
+```
+
+**Enable during BMAD installation** by answering "Yes" when prompted.
+
+**Supported utilities (11 total):**
+
+- api-request, network-recorder, auth-session, intercept-network-call, recurse
+- log, file-utils, burn-in, network-error-monitor
+- fixtures-composition (integration patterns)
+
+**Workflows adapt:** automate, framework, test-review, ci, atdd (+ light mention in test-design).
+
+**Knowledge base:** 32 total fragments (21 core patterns + 11 playwright-utils)
+
 </details>
 
 ## High-Level Cheat Sheets
@@ -237,22 +259,22 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
 
 **🔄 Brownfield Deltas from Greenfield:**
 
-- ➕ Phase 0 (Documentation) - Document existing codebase if undocumented
+- ➕ Documentation (Prerequisite) - Document existing codebase if undocumented
 - ➕ Phase 2: `*trace` - Baseline existing test coverage before planning
 - 🔄 Phase 4: `*test-design` - Focus on regression hotspots and brownfield risks
 - 🔄 Phase 4: Story Review - May include `*nfr-assess` if not done earlier
 
-| Workflow Stage                | Test Architect                                                               | Dev / Team                                                                          | Outputs                                                                |
-| ----------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
-| **Phase 0**: Documentation ➕ | -                                                                            | Analyst `*document-project` (if undocumented)                                       | Comprehensive project documentation                                    |
-| **Phase 1**: Discovery        | -                                                                            | Analyst/PM/Architect rerun planning workflows                                       | Updated planning artifacts in `{output_folder}`                        |
-| **Phase 2**: Planning         | Run ➕ `*trace` (baseline coverage)                                          | PM `*prd` (creates PRD with FRs/NFRs)                                               | PRD with FRs/NFRs, ➕ coverage baseline                                |
-| **Phase 3**: Solutioning      | Run `*framework`, `*ci` AFTER architecture and epic creation                 | Architect `*architecture`, `*create-epics-and-stories`, `*implementation-readiness` | Architecture, epics/stories, test framework, CI pipeline               |
-| **Phase 4**: Sprint Start     | -                                                                            | SM `*sprint-planning`                                                               | Sprint status file with all epics and stories                          |
-| **Phase 4**: Epic Planning    | Run `*test-design` for THIS epic 🔄 (regression hotspots)                    | Review epic scope and brownfield risks                                              | `test-design-epic-N.md` with brownfield risk assessment and mitigation |
-| **Phase 4**: Story Dev        | (Optional) `*atdd` before dev, then `*automate` after                        | SM `*create-story`, DEV implements                                                  | Tests, story implementation                                            |
-| **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                             |
+| Workflow Stage                     | Test Architect                                                               | Dev / Team                                                                          | Outputs                                                                |
+| ---------------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
+| **Documentation**: Prerequisite ➕ | -                                                                            | Analyst `*document-project` (if undocumented)                                       | Comprehensive project documentation                                    |
+| **Phase 1**: Discovery             | -                                                                            | Analyst/PM/Architect rerun planning workflows                                       | Updated planning artifacts in `{output_folder}`                        |
+| **Phase 2**: Planning              | Run ➕ `*trace` (baseline coverage)                                          | PM `*prd` (creates PRD with FRs/NFRs)                                               | PRD with FRs/NFRs, ➕ coverage baseline                                |
+| **Phase 3**: Solutioning           | Run `*framework`, `*ci` AFTER architecture and epic creation                 | Architect `*architecture`, `*create-epics-and-stories`, `*implementation-readiness` | Architecture, epics/stories, test framework, CI pipeline               |
+| **Phase 4**: Sprint Start          | -                                                                            | SM `*sprint-planning`                                                               | Sprint status file with all epics and stories                          |
+| **Phase 4**: Epic Planning         | Run `*test-design` for THIS epic 🔄 (regression hotspots)                    | Review epic scope and brownfield risks                                              | `test-design-epic-N.md` with brownfield risk assessment and mitigation |
+| **Phase 4**: Story Dev             | (Optional) `*atdd` before dev, then `*automate` after                        | SM `*create-story`, DEV implements                                                  | Tests, story implementation                                            |
+| **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>
@@ -295,7 +317,7 @@ These cheat sheets map TEA workflows to the **BMad Method and Enterprise tracks*
 | Workflow Stage             | Test Architect                                                           | Dev / Team                                                                          | Outputs                                                            |
 | -------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
 | **Phase 1**: Discovery     | -                                                                        | Analyst ➕ `*research`, `*product-brief`                                            | Domain research, compliance analysis, product brief                |
-| **Phase 2**: Planning      | Run ➕ `*nfr-assess`                                                     | PM `*prd` (creates PRD with FRs/NFRs), UX `*create-design`                          | Enterprise PRD with FRs/NFRs, UX design, ➕ NFR documentation      |
+| **Phase 2**: Planning      | Run ➕ `*nfr-assess`                                                     | PM `*prd` (creates PRD with FRs/NFRs), UX `*create-ux-design`                       | Enterprise PRD with FRs/NFRs, UX design, ➕ NFR documentation      |
 | **Phase 3**: Solutioning   | Run `*framework`, `*ci` AFTER architecture and epic creation             | Architect `*architecture`, `*create-epics-and-stories`, `*implementation-readiness` | Architecture, epics/stories, test framework, CI pipeline           |
 | **Phase 4**: Sprint Start  | -                                                                        | SM `*sprint-planning`                                                               | Sprint plan with all epics                                         |
 | **Phase 4**: Epic Planning | Run `*test-design` for THIS epic 🔄 (compliance focus)                   | Review epic scope and compliance requirements                                       | `test-design-epic-N.md` with security/performance/compliance focus |
@@ -380,6 +402,50 @@ MCP provides additional capabilities on top of TEA's default AI-based approach:
 
 </details>
 
+<details>
+<summary><strong>Optional Playwright Utils Integration</strong></summary>
+
+**Open-source Playwright utilities** from SEON Technologies (production-tested, npm published):
+
+- **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`
+
+**How Playwright Utils Enhances TEA Workflows**:
+
+Provides fixture-based utilities that integrate into TEA's test generation and review workflows:
+
+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 (21 fragments)
+   - **+ playwright-utils**: Reviews against expanded knowledge base (32 fragments: 21 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** (11 total): api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor, fixtures-composition
+
+**Enable during BMAD installation** by answering "Yes" when prompted, or manually set `tea_use_playwright_utils: true` in `{bmad_folder}/bmm/config.yaml`.
+
+**To disable**: Set `tea_use_playwright_utils: false` in `{bmad_folder}/bmm/config.yaml`.
+
+</details>
+
 <br></br>
 
 | Command        | Workflow README                                   | Primary Outputs                                                                               | Notes                                                | With Playwright MCP Enhancements                                                                             |