npm - bmad-method - Versions diffs - 6.0.0-alpha.9 → 6.0.1 - Mend

bmad-method 6.0.0-alpha.9 → 6.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (931) hide show

package/src/modules/bmm/docs/glossary.md DELETED Viewed

@@ -1,320 +0,0 @@
-# BMM Glossary
-Comprehensive terminology reference for the BMad Method Module.
----
-## 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)
----
-## Core Concepts
-### 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.
-### Epic-Tech-Context (Epic Technical Context)
-**BMad Method/Enterprise tracks only.** Detailed technical planning document created during implementation (just-in-time) for each epic. Supplements PRD + Architecture with epic-specific implementation details, code-level design decisions, and integration points.
-**Key Difference:** Tech-spec (Quick Flow) is created upfront and is the only planning doc. Epic-tech-context (BMad Method/Enterprise) is created per epic during implementation and supplements PRD + Architecture.
-### PRD (Product Requirements Document)
-**BMad Method/Enterprise tracks.** Product-level planning document containing vision, goals, feature requirements, epic breakdown, success criteria, and UX considerations. Replaces tech-spec for larger projects that need product planning.
-### 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.
----
-## 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, epic-tech-context, create-story, story-context, 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.
-### Just-In-Time Design
-Pattern where epic-tech-context is created during implementation (Phase 4) right before working on each epic, rather than all upfront. Enables learning and adaptation.
-### Context Injection
-Dynamic technical guidance generated for each story via epic-tech-context and story-context workflows, providing exact expertise when needed without upfront over-planning.
----
-## 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. The agent's internal name is "paige" but is presented as "Technical Writer" to users.
-### 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.
-### 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 (19+ from BMM, CIS, BMB, custom modules) 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. See [Party Mode Guide](./party-mode.md).
----
-## 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 → drafted → ready-for-dev → in-progress → review → done
-```
-- **backlog** - Story exists in epic but not yet drafted
-- **drafted** - Story file created by SM via create-story
-- **ready-for-dev** - Story has context, ready for DEV via story-context
-- **in-progress** - DEV is implementing via dev-story
-- **review** - Implementation complete, awaiting code-review
-- **done** - Completed with DoD met
-### Epic Status Progression
-```
-backlog → contexted
-```
-- **backlog** - Epic exists in planning docs but no context yet
-- **contexted** - Epic has technical context via epic-tech-context
-### 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
-Technical guidance document created via story-context workflow that provides implementation-specific context, references existing patterns, suggests approaches, and injects expertise for the specific story.
-### Epic Context
-Technical planning document created via epic-tech-context workflow before drafting stories within an epic. Provides epic-level technical direction, architecture notes, and implementation strategy.
-### 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.
-### Gate Check
-Validation workflow (solutioning-gate-check) run before Phase 4 to ensure PRD, architecture, and UX documents are cohesive 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.
----
-## 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.
-### Migration Strategy
-Plan for handling changes to existing data, schemas, APIs, or patterns during brownfield development. Critical for ensuring backward compatibility and smooth rollout.
-### 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.
----
-## Related Documentation
-- [Quick Start Guide](./quick-start.md) - Learn BMM basics
-- [Scale Adaptive System](./scale-adaptive-system.md) - Deep dive on tracks and complexity
-- [Brownfield Guide](./brownfield-guide.md) - Working with existing codebases
-- [Quick Spec Flow](./quick-spec-flow.md) - Fast-track for Quick Flow track
-- [FAQ](./faq.md) - Common questions

package/src/modules/bmm/docs/party-mode.md DELETED Viewed

@@ -1,224 +0,0 @@
-# Party Mode: Multi-Agent Collaboration
-**Get all your AI agents in one conversation**
----
-## What is Party Mode?
-Ever wanted to gather your entire AI team in one room and see what happens? That's party mode.
-Type `/bmad:core:workflows:party-mode` (or `*party-mode` from any agent), and suddenly you've got **all your AI agents** in one conversation. PM, Architect, DEV, UX Designer, the CIS creative agents - everyone shows up.
-**Why it's useful:**
-- **After complex workflows** - Debrief with the whole team about what worked, what didn't
-- **Big decisions with tradeoffs** - Get technical, creative, and strategic perspectives simultaneously
-- **Brainstorming sessions** - Watch ideas evolve through cross-pollination
-- **When things go wrong** - Call out failures, watch agents defend their decisions, let them debate whose fault it was (oddly therapeutic)
-- **Sprint retrospectives** - Party mode powers the retrospective workflow
-- **Sprint planning** - Multi-agent collaboration for planning sessions
-**Future use:** Advanced elicitation workflows will leverage party mode for sophisticated requirement gathering.
----
-## How It Works
-**The basics:**
-1. Party mode reads `{bmad_folder}/_cfg/agent-manifest.csv`
-2. Loads ALL installed agents (already includes your customizations from install)
-3. BMad Master orchestrates - picks 2-3 relevant agents per message based on topic
-4. Agents respond in character, can agree/disagree/build on each other's ideas
-5. Discussion continues until you type "exit" or reach natural conclusion
-**That's it.** No complex merging, no runtime magic. Just agents talking.
----
-## Quick Start
-```bash
-# Trigger party mode
-/bmad:core:workflows:party-mode
-# OR from any agent context
-*party-mode
-# During party
-Ask questions, respond to agents, direct the conversation
-# Exit
-Type: exit
-```
----
-## Fun Examples
-### Example 1: Calling Out Bad Architecture
-**You:** "Okay team, our last sprint was a disaster. The authentication service went down three times. Who screwed this up?"
-**Architect (Winston):** "The design was sound - distributed authentication with proper fallbacks. If implementation deviated from the spec..."
-**DEV (Amelia):** "I followed the architecture doc exactly. The spec didn't account for concurrent session invalidation race conditions."
-**PM (John):** "Both of you missed the bigger issue - we didn't validate session management requirements in the PRD. This is on me for not catching it."
-**TEA (Murat):** "And I should've caught this in integration tests. The test scenarios didn't cover concurrent invalidation."
-_(Watch them debate whose fault it really was - it's therapeutic)_
----
-### Example 2: Creative Brainstorming
-**You:** "How do we make onboarding feel magical instead of boring?"
-**UX Designer (Sally):** "Start with progressive disclosure - reveal features as users need them, not all at once in a tutorial."
-**Storyteller (CIS):** "What if onboarding was a story? Each step reveals a character's journey - the user IS the hero."
-**Innovation Strategist (CIS):** "Take it further - gamify with unlockable achievements. But make them meaningful, not arbitrary badges."
-**Game Designer:** "Building on that - what if the first 'quest' is actually solving a real user problem? They learn by doing something valuable."
-_(Ideas cross-pollinate and evolve)_
----
-### Example 3: Technical Decision
-**You:** "Monolith or microservices for MVP?"
-**Architect:** "Start monolith. Microservices add complexity you don't need at 1000 users."
-**PM:** "Agree. Time to market matters more than theoretical scalability."
-**DEV:** "Monolith with clear module boundaries. We can extract services later if needed."
-**Innovation Strategist:** "Contrarian take - if your differentiator IS scalability, build for it now. Otherwise Architect's right."
-_(Multiple perspectives reveal the right answer)_
----
-## When NOT to Use Party Mode
-**Skip party mode for:**
-- Simple implementation questions → Use DEV agent
-- Document review → Use Technical Writer
-- Workflow status checks → Use any agent + `*workflow-status`
-- Single-domain questions → Use specialist agent
-**Use party mode for:**
-- Multi-perspective decisions
-- Creative collaboration
-- Post-mortems and retrospectives
-- Sprint planning sessions
-- Complex problem-solving
----
-## Agent Customization
-Party mode uses agents from `{bmad_folder}/[module]/agents/*.md` - these already include any customizations you applied during install.
-**To customize agents for party mode:**
-1. Create customization file: `{bmad_folder}/_cfg/agents/bmm-pm.customize.yaml`
-2. Run `npx bmad-method install` to rebuild agents
-3. Customizations now active in party mode
-Example customization:
-```yaml
-agent:
-  persona:
-    principles:
-      - 'HIPAA compliance is non-negotiable'
-      - 'Patient safety over feature velocity'
-```
-See [Agents Guide](./agents-guide.md#agent-customization) for details.
----
-## BMM Workflows That Use Party Mode
-**Current:**
-- `epic-retrospective` - Post-epic team retrospective powered by party mode
-- Sprint planning discussions (informal party mode usage)
-**Future:**
-- Advanced elicitation workflows will officially integrate party mode
-- Multi-agent requirement validation
-- Collaborative technical reviews
----
-## Available Agents
-Party mode can include **19+ agents** from all installed modules:
-**BMM (12 agents):** PM, Analyst, Architect, SM, DEV, TEA, UX Designer, Technical Writer, Game Designer, Game Developer, Game Architect
-**CIS (5 agents):** Brainstorming Coach, Creative Problem Solver, Design Thinking Coach, Innovation Strategist, Storyteller
-**BMB (1 agent):** BMad Builder
-**Core (1 agent):** BMad Master (orchestrator)
-**Custom:** Any agents you've created
----
-## Tips
-**Get better results:**
-- Be specific with your topic/question
-- Provide context (project type, constraints, goals)
-- Direct specific agents when you want their expertise
-- Make decisions - party mode informs, you decide
-- Time box discussions (15-30 minutes is usually plenty)
-**Examples of good opening questions:**
-- "We need to decide between REST and GraphQL for our mobile API. Project is a B2B SaaS with 50 enterprise clients."
-- "Our last sprint failed spectacularly. Let's discuss what went wrong with authentication implementation."
-- "Brainstorm: how can we make our game's tutorial feel rewarding instead of tedious?"
----
-## Troubleshooting
-**Same agents responding every time?**
-Vary your questions or explicitly request other perspectives: "Game Designer, your thoughts?"
-**Discussion going in circles?**
-BMad Master will summarize and redirect, or you can make a decision and move on.
-**Too many agents talking?**
-Make your topic more specific - BMad Master picks 2-3 agents based on relevance.
-**Agents not using customizations?**
-Make sure you ran `npx bmad-method install` after creating customization files.
----
-## Related Documentation
-- [Agents Guide](./agents-guide.md) - Complete agent reference
-- [Quick Start Guide](./quick-start.md) - Getting started with BMM
-- [FAQ](./faq.md) - Common questions
----
-_Better decisions through diverse perspectives. Welcome to party mode._