Skip to content
🤖 Consolidated, AI-optimized BMAD docs: llms-full.txt. Fetch this plain text file for complete context.

BMad Glossary

Terminology reference for the BMad Method.

TermDefinition
AgentSpecialized AI persona with specific expertise (PM, Architect, SM, DEV, TEA) that guides users through workflows and creates deliverables.
BMadBreakthrough Method of Agile AI-Driven Development — AI-driven agile framework with specialized agents, guided workflows, and scale-adaptive intelligence.
BMad MethodComplete methodology for AI-assisted software development, encompassing planning, architecture, implementation, and quality assurance workflows that adapt to project complexity.
BMMBMad Method Module — core orchestration system providing comprehensive lifecycle management through specialized agents and workflows.
Scale-Adaptive SystemIntelligent workflow orchestration that adjusts planning depth and documentation requirements based on project needs through three planning tracks.
WorkflowMulti-step guided process that orchestrates AI agent activities to produce specific deliverables. Workflows are interactive and adapt to user context.
TermDefinition
BMad Method TrackFull product planning track using PRD + Architecture + UX. Best for products, platforms, and complex features. Typical range: 10-50+ stories.
Enterprise Method TrackExtended planning track adding Security Architecture, DevOps Strategy, and Test Strategy. Best for compliance needs and multi-tenant systems. Typical range: 30+ stories.
Planning TrackMethodology path (Quick Flow, BMad Method, or Enterprise) chosen based on planning needs and complexity, not story count alone.
Quick Flow TrackFast implementation track using tech-spec only. Best for bug fixes, small features, and clear-scope changes. Typical range: 1-15 stories.
TermDefinition
Architecture DocumentBMad Method/Enterprise. System-wide design document defining structure, components, data models, integration patterns, security, and deployment.
EpicsHigh-level feature groupings containing multiple related stories. Typically 5-15 stories each representing cohesive functionality.
Game BriefBMGD. Document capturing game’s core vision, pillars, target audience, and scope. Foundation for the GDD.
GDDBMGD. Game Design Document — comprehensive document detailing all aspects of game design: mechanics, systems, content, and more.
PRDBMad Method/Enterprise. Product Requirements Document containing vision, goals, FRs, NFRs, and success criteria. Focuses on WHAT to build.
Product BriefPhase 1. Optional strategic document capturing product vision, market context, and high-level requirements before detailed planning.
Tech-SpecQuick Flow only. Comprehensive technical plan with problem statement, solution approach, file-level changes, and testing strategy.
TermDefinition
Phase 0: DocumentationBrownfield. Conditional prerequisite phase creating codebase documentation before planning. Only required if existing docs are insufficient.
Phase 1: AnalysisDiscovery phase including brainstorming, research, and product brief creation. Optional for Quick Flow, recommended for BMad Method.
Phase 2: PlanningRequired phase creating formal requirements. Routes to tech-spec (Quick Flow) or PRD (BMad Method/Enterprise).
Phase 3: SolutioningBMad Method/Enterprise. Architecture design phase including creation, validation, and gate checks.
Phase 4: ImplementationRequired sprint-based development through story-by-story iteration using sprint-planning, create-story, dev-story, and code-review workflows.
Quick Spec FlowFast-track workflow for Quick Flow projects going straight from idea to tech-spec to implementation.
Workflow InitInitialization workflow creating bmm-workflow-status.yaml, detecting project type, and determining planning track.
Workflow StatusUniversal entry point checking for existing status file, displaying progress, and recommending next action.
TermDefinition
AnalystAgent that initializes workflows, conducts research, creates product briefs, and tracks progress. Often the entry point for new projects.
ArchitectAgent designing system architecture, creating architecture documents, and validating designs. Primary agent for Phase 3.
BMad MasterMeta-level orchestrator from BMad Core facilitating party mode and providing high-level guidance across all modules.
DEVDeveloper agent implementing stories, writing code, running tests, and performing code reviews. Primary implementer in Phase 4.
Game ArchitectBMGD. Agent designing game system architecture and validating game-specific technical designs.
Game DesignerBMGD. Agent creating game design documents (GDD) and running game-specific workflows.
Party ModeMulti-agent collaboration feature where agents discuss challenges together. BMad Master orchestrates, selecting 2-3 relevant agents per message.
PMProduct Manager agent creating PRDs and tech-specs. Primary agent for Phase 2 planning.
SMScrum Master agent managing sprints, creating stories, and coordinating implementation. Primary orchestrator for Phase 4.
TEATest Architect agent responsible for test strategy, quality gates, and NFR assessment. Integrates throughout all phases.
Technical WriterAgent specialized in creating technical documentation, diagrams, and maintaining documentation standards.
UX DesignerAgent creating UX design documents, interaction patterns, and visual specifications for UI-heavy projects.
TermDefinition
bmm-workflow-status.yamlPhases 1-3. Tracking file showing current phase, completed workflows, and next recommended actions.
DoDDefinition of Done — criteria for marking a story complete: implementation done, tests passing, code reviewed, docs updated.
Epic Status Progressionbacklog → in-progress → done — lifecycle states for epics during implementation.
Gate CheckValidation workflow (implementation-readiness) ensuring PRD, Architecture, and Epics are aligned before Phase 4.
RetrospectiveWorkflow after each epic capturing learnings and improvements for continuous improvement.
sprint-status.yamlPhase 4. Single source of truth for implementation tracking containing all epics, stories, and their statuses.
Story Status Progressionbacklog → ready-for-dev → in-progress → review → done — lifecycle states for stories.
TermDefinition
BrownfieldExisting project with established codebase and patterns. Requires understanding existing architecture and planning integration.
Convention DetectionQuick Flow. Feature auto-detecting existing code style, naming conventions, and frameworks from brownfield codebases.
document-projectBrownfield. Workflow analyzing and documenting existing codebase with three scan levels: quick, deep, exhaustive.
Feature FlagsBrownfield. Implementation technique for gradual rollout, easy rollback, and A/B testing of new functionality.
GreenfieldNew project starting from scratch with freedom to establish patterns, choose stack, and design from clean slate.
Integration PointsBrownfield. Specific locations where new code connects with existing systems. Must be documented in tech-specs.
TermDefinition
Context EngineeringLoading domain-specific standards into AI context automatically via manifests, ensuring consistent outputs regardless of prompt variation.
Correct CourseWorkflow for navigating significant changes when implementation is off-track. Analyzes impact and recommends adjustments.
Shard / ShardingSplitting large planning documents into section-based files for LLM optimization. Phase 4 workflows load only needed sections.
SprintTime-boxed period of development work, typically 1-2 weeks.
Sprint PlanningWorkflow initializing Phase 4 by creating sprint-status.yaml and extracting epics/stories from planning docs.
StorySingle unit of implementable work with clear acceptance criteria, typically 2-8 hours of effort. Grouped into epics.
Story ContextImplementation guidance embedded in story files during create-story, referencing existing patterns and approaches.
Story FileMarkdown file containing story description, acceptance criteria, technical notes, and testing requirements.
Track SelectionAutomatic analysis by bmad-help suggesting appropriate track based on complexity indicators. User can override.
TermDefinition
Core FantasyBMGD. The emotional experience players seek from your game — what they want to FEEL.
Core LoopBMGD. Fundamental cycle of actions players repeat throughout gameplay. The heart of your game.
Design PillarBMGD. Core principle guiding all design decisions. Typically 3-5 pillars define a game’s identity.
Environmental StorytellingBMGD. Narrative communicated through the game world itself rather than explicit dialogue.
Game TypeBMGD. Genre classification determining which specialized GDD sections are included.
MDA FrameworkBMGD. Mechanics → Dynamics → Aesthetics — framework for analyzing and designing games.
Meta-ProgressionBMGD. Persistent progression carrying between individual runs or sessions.
MetroidvaniaBMGD. Genre featuring interconnected world exploration with ability-gated progression.
Narrative ComplexityBMGD. How central story is to the game: Critical, Heavy, Moderate, or Light.
PermadeathBMGD. Game mechanic where character death is permanent, typically requiring a new run.
Player AgencyBMGD. Degree to which players can make meaningful choices affecting outcomes.
Procedural GenerationBMGD. Algorithmic creation of game content (levels, items, characters) rather than hand-crafted.
RoguelikeBMGD. Genre featuring procedural generation, permadeath, and run-based progression.
TermDefinition
ATDDAcceptance Test-Driven Development — Generating failing acceptance tests BEFORE implementation (TDD red phase).
Burn-in TestingRunning tests multiple times (typically 5-10 iterations) to detect flakiness and intermittent failures.
Component TestingTesting UI components in isolation using framework-specific tools (Cypress Component Testing or Vitest + React Testing Library).
Coverage TraceabilityMapping acceptance criteria to implemented tests with classification (FULL/PARTIAL/NONE) to identify gaps and measure completeness.
Epic-Level Test DesignTest planning per epic (Phase 4) focusing on risk assessment, priorities, and coverage strategy for that specific epic.
Fixture ArchitecturePattern of building pure functions first, then wrapping in framework-specific fixtures for testability, reusability, and composition.
Gate DecisionGo/no-go decision for release with four outcomes: PASS ✅ (ready), CONCERNS ⚠️ (proceed with mitigation), FAIL ❌ (blocked), WAIVED ⏭️ (approved despite issues).
Knowledge FragmentIndividual markdown file in TEA’s knowledge base covering a specific testing pattern or practice (33 fragments total).
MCP EnhancementsModel Context Protocol servers enabling live browser verification during test generation (exploratory, recording, and healing modes).
Network-First PatternTesting pattern that waits for actual network responses instead of fixed timeouts to avoid race conditions and flakiness.
NFR AssessmentValidation of non-functional requirements (security, performance, reliability, maintainability) with evidence-based decisions.
Playwright UtilsOptional package (@seontechnologies/playwright-utils) providing production-ready fixtures and utilities for Playwright tests.
Risk-Based TestingTesting approach where depth scales with business impact using probability × impact scoring (1-9 scale).
System-Level Test DesignTest planning at architecture level (Phase 3) focusing on testability review, ADR mapping, and test infrastructure needs.
tea-index.csvManifest file tracking all knowledge fragments, their descriptions, tags, and which workflows load them.
TEA IntegratedFull BMad Method integration with TEA workflows across all phases (Phase 2, 3, 4, and Release Gate).
TEA LiteBeginner approach using just automate to test existing features (simplest way to use TEA).
TEA SoloStandalone engagement model using TEA without full BMad Method integration (bring your own requirements).
Test PrioritiesClassification system for test importance: P0 (critical path), P1 (high value), P2 (medium value), P3 (low value).


Generated with BMad Method