bmad-fh 6.0.0-alpha.052779ef

package/docs/reference/agents/index.md

@@ -0,0 +1,109 @@
+---
+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
+
+## 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
+
+## 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
+
+## 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
+
+## DEV (Amelia)
+
+Story implementation and code review.
+
+**Commands:**
+- `*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
+
+## 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
+
+## 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
+
+## 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

package/docs/reference/configuration/core-tasks.md

@@ -0,0 +1,67 @@
+---
+title: "Core Tasks"
+---
+
+Reusable task definitions that can be invoked by any BMad module, workflow, or agent.
+
+## Contents
+
+- [Index Docs](#index-docs) — Generate directory index files
+- [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 files in a specified directory.**
+
+**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
+4. Create or update index.md with organized listings
+
+**Output:** Markdown index with sections for Files and Subdirectories, each entry containing a relative link and description.
+
+## Adversarial Review
+
+**Performs a cynical, skeptical review of any content to identify issues and improvement opportunities.**
+
+**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, 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[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 files based on level 2 (`##`) sections.**
+
+**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 (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 original document — delete, move to archive, or keep
+
+:::caution[Original File]
+After sharding, delete or archive the original to avoid confusion. Updates should happen in the sharded files only.
+:::

package/docs/reference/configuration/global-config.md

@@ -0,0 +1,28 @@
+---
+title: "Global Inheritable Config"
+---
+
+Configuration values defined in the Core Module that all other modules inherit by default.
+
+## Core Config Values
+
+These values are set during installation and recorded to the core `module.yaml`:
+
+| 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.
+:::

package/docs/reference/glossary/index.md

@@ -0,0 +1,159 @@
+---
+title: "BMad Glossary"
+---
+
+Terminology reference for the BMad Method.
+
+## Core Concepts
+
+| 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
+
+| 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
+
+| 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
+
+| 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
+
+| 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
+
+| 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
+
+| 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
+
+| 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
+
+| 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.                |
+
+## Test Architect (TEA) Concepts
+
+| 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).                                            |
+
+---
+
+## See Also
+
+- [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
+
+---
+
+Generated with [BMad Method](https://bmad-method.org)

package/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)