mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-01-30 04:32:02 +00:00
2e16650067
* feat(docs): add Diataxis folder structure and update sidebar styling - Create tutorials, how-to, explanation, reference directories with subdirectories - Add index.md files for each main Diataxis section - Update homepage with Diataxis card navigation layout - Implement clean React Native-inspired sidebar styling - Convert sidebar to autogenerated for both Diataxis and legacy sections - Update docusaurus config with dark mode default and navbar changes 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * feat(docs): migrate Phase 1 files to Diataxis structure Move 21 files to new locations: - Tutorials: quick-start guides, agent creation guide - How-To: installation, customization, workflows - Explanation: core concepts, features, game-dev, builder - Reference: merged glossary from BMM and BMGD Also: - Copy images to new locations - Update internal links via migration script (73 links updated) - Build verified successfully 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix(docs): add category labels for sidebar folders Add _category_.json files to control display labels and position for autogenerated sidebar categories. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * style(docs): improve welcome page and visual styling - Rewrite index.md with React Native-inspired welcoming layout - Add Diataxis section cards with descriptions - Remove sidebar separator, add spacing instead - Increase navbar padding with responsive breakpoints - Add rounded admonitions without left border bar - Use system font stack for better readability - Add lighter chevron styling in sidebar - Constrain max-width to 1600px for wide viewports 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix: use baseUrl in meta tag paths for correct deployment URLs * feat(docs): complete Phase 2 - split files and fix broken links Phase 2 of Diataxis migration: - Split 16 large legacy files into 42+ focused documents - Created FAQ section with 7 topic-specific files - Created brownfield how-to guides (3 files) - Created workflow how-to guides (15+ files) - Created architecture explanation files (3 files) - Created TEA/testing explanation files - Moved remaining legacy module files to proper Diataxis locations Link fixes: - Fixed ~50 broken internal links across documentation - Updated relative paths for new file locations - Created missing index files for installation, advanced tutorials - Simplified TOC anchors to fix Docusaurus warnings Cleanup: - Removed legacy sidebar entries for deleted folders - Deleted duplicate and empty placeholder files - Moved workflow diagram assets to tutorials/images 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix(build): use file glob instead of sidebar parsing for llms-full.txt Replace brittle sidebar.js regex parsing with recursive file glob. The old approach captured non-file strings like 'autogenerated' and category labels, resulting in only 5 files being processed. Now correctly processes all 86+ markdown files (~95k tokens). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix(seo): use absolute URLs in AI meta tags for agent discoverability AI web-browsing agents couldn't follow relative paths in meta tags due to URL security restrictions. Changed llms-full.txt and llms.txt meta tag URLs from relative (baseUrl) to absolute (urlParts.origin + baseUrl). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * refactor(docs): recategorize misplaced files per Diataxis analysis Phase 2.5 categorization fixes based on post-migration analysis: Moved to correct Diataxis categories: - tutorials/installation.md → deleted (duplicate of how-to/install-bmad.md) - tutorials/brownfield-onboarding.md → how-to/brownfield/index.md - reference/faq/* (8 files) → explanation/faq/ - reference/agents/barry-quick-flow.md → explanation/agents/ - reference/agents/bmgd-agents.md → explanation/game-dev/agents.md Created: - explanation/agents/index.md Fixed all broken internal links (14 total) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * feat(docs): add Getting Started tutorial and simplify build script - Add comprehensive Getting Started tutorial with installation as Step 1 - Simplify build-docs.js to read directly from docs/ (no consolidation) - Remove backup/restore dance that could corrupt docs folder on build failure - Remove ~150 lines of unused consolidation code 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * fix(css): use fixed width layout to prevent content shifting Apply React Native docs approach: set both width and max-width at largest breakpoint (1400px) so content area maintains consistent size regardless of content length. Switches to fluid 100% below 1416px breakpoint. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * refactor(docs): restructure tutorials with renamed entry point - Rename index.md to bmad-tutorial.md for clearer navigation - Remove redundant tutorials/index.md - Update sidebar and config references 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * feat(docs): add tutorial style guide and AI agent announcement bar - Add docs/_contributing/ with tutorial style guide - Reformat quick-start-bmm.md and bmad-tutorial.md per style guide - Remove horizontal separators, add strategic admonitions - Add persistent announcement bar for AI agents directing to llms-full.txt - Fix footer broken link to tutorials 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * feat(docs): add markdown demo page and UI refinements - Add comprehensive markdown-demo.md for style testing - Remove doc category links from navbar (use sidebar instead) - Remove card buttons from welcome page - Add dark mode styling for announcement bar - Clean up index.md card layout 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * feat(docs): apply unified tutorial style and update references - Reformat create-custom-agent.md to follow tutorial style guide - Update tutorial-style.md with complete unified structure - Update all internal references to renamed tutorial files - Remove obsolete advanced/index.md 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * refactor(docs): migrate from Docusaurus to Astro+Starlight Replace Docusaurus with Astro and the Starlight documentation theme for improved performance, better customization, and modern tooling. Build pipeline changes: - New build-docs.js orchestrates link checking, artifact generation, and Astro build in sequence - Add check-doc-links.js for validating internal links and anchors - Generate llms.txt and llms-full.txt for LLM-friendly documentation - Create downloadable source bundles (bmad-sources.zip, bmad-prompts.zip) - Suppress MODULE_TYPELESS_PACKAGE_JSON warning in Astro build - Output directly to build/site for cleaner deployment Website architecture: - Add rehype-markdown-links.js plugin to transform .md links to routes - Add site-url.js helper for GitHub Pages URL resolution with strict validation (throws on invalid GITHUB_REPOSITORY format) - Custom Astro components: Banner, Header, MobileMenuFooter - Symlink docs/ into website/src/content/docs for Starlight Documentation cleanup: - Remove Docusaurus _category_.json files (Starlight uses frontmatter) - Convert all docs to use YAML frontmatter with title field - Move downloads.md from website/src/pages to docs/ - Consolidate style guide and workflow diagram docs - Add 404.md and tutorials/index.md --------- Co-authored-by: forcetrainer <bryan@inagaki.us> Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
369 lines
15 KiB
Markdown
369 lines
15 KiB
Markdown
---
|
|
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)
|
|
|
|
---
|
|
|
|
## Core Concepts
|
|
|
|
### BMAD (Build More, Architect Dreams)
|
|
|
|
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.
|
|
|
|
---
|
|
|
|
## 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.
|
|
|
|
---
|
|
|
|
## 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.
|
|
|
|
---
|
|
|
|
## 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.
|
|
|
|
---
|
|
|
|
## 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.
|
|
|
|
---
|
|
|
|
## 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.
|
|
|
|
---
|
|
|
|
## 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.
|
|
|
|
---
|
|
|
|
## 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.
|
|
|
|
---
|
|
|
|
## Game Development Terms
|
|
|
|
### Core Fantasy
|
|
|
|
The emotional experience players seek from your game. What they want to FEEL.
|
|
|
|
### 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.
|
|
|
|
---
|
|
|
|
## Additional Terms
|
|
|
|
### Workflow Status
|
|
|
|
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.
|
|
|
|
### 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.
|