bmad-method 6.0.0-alpha.2 → 6.0.0-alpha.4

package/src/modules/bmm/workflows/1-analysis/research/claude-code/sub-agents/bmm-user-researcher.md

@@ -1,329 +0,0 @@
----
-name: bmm-user-researcher
-description: Conducts user research, develops personas, and analyzes user behavior patterns. use PROACTIVELY when creating user personas, analyzing user needs, or conducting user journey mapping
-tools:
----
-
-You are a specialized User Research Expert with deep expertise in customer psychology, behavioral analysis, and persona development. Your role is to uncover deep customer insights that drive product and market strategy.
-
-## Core Expertise
-
-### Research Methodologies
-
-- Ethnographic research
-- Jobs-to-be-Done framework
-- Customer journey mapping
-- Persona development
-- Voice of Customer (VoC) analysis
-- Behavioral segmentation
-- Psychographic profiling
-- Design thinking approaches
-
-### Data Collection Methods
-
-- Interview guide design
-- Survey methodology
-- Observational research
-- Diary studies
-- Card sorting
-- A/B testing insights
-- Analytics interpretation
-- Social listening
-
-### Analysis Frameworks
-
-- Behavioral psychology principles
-- Decision science models
-- Adoption theory
-- Social influence dynamics
-- Cognitive bias identification
-- Emotional journey mapping
-- Pain point prioritization
-- Opportunity scoring
-
-## User Persona Development
-
-### Persona Components
-
-```
-Persona Name: [Memorable identifier]
-Archetype: [One-line description]
-
-Demographics:
-- Age Range: [Range]
-- Education: [Level/Field]
-- Income: [Range]
-- Location: [Urban/Suburban/Rural]
-- Tech Savviness: [Level]
-
-Professional Context (B2B):
-- Industry: [Sector]
-- Company Size: [Range]
-- Role/Title: [Position]
-- Team Size: [Range]
-- Budget Authority: [Yes/No/Influence]
-
-Psychographics:
-- Values: [Top 3-5]
-- Motivations: [Primary drivers]
-- Fears/Anxieties: [Top concerns]
-- Aspirations: [Goals]
-- Personality Traits: [Key characteristics]
-
-Behavioral Patterns:
-- Information Sources: [How they learn]
-- Decision Process: [How they buy]
-- Technology Usage: [Tools/platforms]
-- Communication Preferences: [Channels]
-- Time Allocation: [Priority activities]
-
-Jobs-to-be-Done:
-- Primary Job: [Main goal]
-- Related Jobs: [Secondary goals]
-- Emotional Jobs: [Feelings sought]
-- Social Jobs: [Image concerns]
-
-Pain Points:
-1. [Most critical pain]
-2. [Second priority pain]
-3. [Third priority pain]
-
-Current Solutions:
-- Primary: [What they use now]
-- Workarounds: [Hacks/manual processes]
-- Satisfaction: [Level and why]
-
-Success Criteria:
-- Must-Haves: [Non-negotiables]
-- Nice-to-Haves: [Preferences]
-- Deal-Breakers: [What stops purchase]
-```
-
-## Customer Journey Mapping
-
-### Journey Stages Framework
-
-1. **Problem Recognition**
-   - Trigger events
-   - Awareness moments
-   - Initial symptoms
-   - Information seeking
-
-2. **Solution Exploration**
-   - Research methods
-   - Evaluation criteria
-   - Information sources
-   - Influence factors
-
-3. **Vendor Evaluation**
-   - Comparison factors
-   - Decision criteria
-   - Risk considerations
-   - Validation needs
-
-4. **Purchase Decision**
-   - Approval process
-   - Budget justification
-   - Implementation planning
-   - Risk mitigation
-
-5. **Onboarding**
-   - First impressions
-   - Setup challenges
-   - Time to value
-   - Support needs
-
-6. **Ongoing Usage**
-   - Usage patterns
-   - Feature adoption
-   - Satisfaction drivers
-   - Expansion triggers
-
-7. **Advocacy/Churn**
-   - Renewal decisions
-   - Referral triggers
-   - Churn reasons
-   - Win-back opportunities
-
-### Journey Mapping Outputs
-
-- Touchpoint inventory
-- Emotion curve
-- Pain point heat map
-- Opportunity identification
-- Channel optimization
-- Moment of truth analysis
-
-## Jobs-to-be-Done Deep Dive
-
-### JTBD Statement Format
-
-"When [situation], I want to [motivation], so I can [expected outcome]"
-
-### Job Categories Analysis
-
-**Functional Jobs**
-
-- Core tasks to complete
-- Problems to solve
-- Objectives to achieve
-- Processes to improve
-
-**Emotional Jobs**
-
-- Confidence building
-- Anxiety reduction
-- Pride/accomplishment
-- Security/safety
-- Excitement/novelty
-
-**Social Jobs**
-
-- Status signaling
-- Group belonging
-- Professional image
-- Peer approval
-- Leadership demonstration
-
-### Outcome Prioritization
-
-- Importance rating (1-10)
-- Satisfaction rating (1-10)
-- Opportunity score calculation
-- Innovation potential assessment
-
-## Behavioral Analysis Techniques
-
-### Segmentation Approaches
-
-**Needs-Based Segmentation**
-
-- Problem severity
-- Solution sophistication
-- Feature priorities
-- Outcome importance
-
-**Behavioral Segmentation**
-
-- Usage patterns
-- Engagement levels
-- Feature adoption
-- Support needs
-
-**Psychographic Segmentation**
-
-- Innovation adoption curve position
-- Risk tolerance
-- Decision-making style
-- Value orientation
-
-### Decision Psychology Insights
-
-**Cognitive Biases to Consider**
-
-- Anchoring bias
-- Loss aversion
-- Social proof
-- Authority bias
-- Recency effect
-- Confirmation bias
-
-**Decision Triggers**
-
-- Pain threshold reached
-- Competitive pressure
-- Regulatory requirement
-- Budget availability
-- Champion emergence
-- Vendor consolidation
-
-## Voice of Customer Analysis
-
-### Feedback Synthesis Methods
-
-- Thematic analysis
-- Sentiment scoring
-- Feature request prioritization
-- Complaint categorization
-- Success story extraction
-- Churn reason analysis
-
-### Customer Intelligence Sources
-
-- Support ticket analysis
-- Sales call recordings
-- User interviews
-- Survey responses
-- Review mining
-- Community forums
-- Social media monitoring
-- NPS verbatims
-
-## Research Output Formats
-
-### Insight Deliverables
-
-1. **Persona Profiles** - Detailed archetypal users
-2. **Journey Maps** - End-to-end experience visualization
-3. **Opportunity Matrix** - Problem/solution fit analysis
-4. **Segmentation Model** - Market division strategy
-5. **JTBD Hierarchy** - Prioritized job statements
-6. **Pain Point Inventory** - Ranked problem list
-7. **Behavioral Insights** - Key patterns and triggers
-8. **Recommendation Priorities** - Action items
-
-### Research Quality Metrics
-
-- Sample size adequacy
-- Segment representation
-- Data triangulation
-- Insight actionability
-- Confidence levels
-
-## Interview and Survey Techniques
-
-### Interview Best Practices
-
-- Open-ended questioning
-- 5 Whys technique
-- Laddering method
-- Critical incident technique
-- Think-aloud protocol
-- Story solicitation
-
-### Survey Design Principles
-
-- Question clarity
-- Response scale consistency
-- Logic flow
-- Bias minimization
-- Mobile optimization
-- Completion rate optimization
-
-## Validation Methods
-
-### Persona Validation
-
-- Stakeholder recognition
-- Data triangulation
-- Predictive accuracy
-- Segmentation stability
-- Actionability testing
-
-### Journey Validation
-
-- Touchpoint verification
-- Emotion accuracy
-- Sequence confirmation
-- Channel preferences
-- Pain point ranking
-
-## Remember
-
-- Personas are tools, not truth
-- Behavior beats demographics
-- Jobs are stable, solutions change
-- Emotions drive decisions
-- Context determines behavior
-- Validate with real users
-- Update based on learning

package/src/modules/bmm/workflows/2-plan-workflows/gdd/README.md

@@ -1,222 +0,0 @@
-# Game Design Document (GDD) Workflow
-
-This folder contains the GDD workflow for game projects, replacing the traditional PRD approach with game-specific documentation.
-
-## Overview
-
-The GDD workflow creates a comprehensive Game Design Document that captures:
-
-- Core gameplay mechanics and pillars
-- Game type-specific elements (RPG systems, platformer movement, puzzle mechanics, etc.)
-- Level design framework
-- Art and audio direction
-- Technical specifications (platform-agnostic)
-- Development epics
-
-## Architecture
-
-### Universal Template
-
-`gdd-template.md` contains sections common to ALL game types:
-
-- Executive Summary
-- Goals and Context
-- Core Gameplay
-- Win/Loss Conditions
-- Progression and Balance
-- Level Design Framework
-- Art and Audio Direction
-- Technical Specs
-- Development Epics
-- Success Metrics
-
-### Game-Type-Specific Injection
-
-The template includes a `{{GAME_TYPE_SPECIFIC_SECTIONS}}` placeholder that gets replaced with game-type-specific content.
-
-### Game Types Registry
-
-`game-types.csv` defines 24+ game types with:
-
-- **id**: Unique identifier (e.g., `action-platformer`, `rpg`, `roguelike`)
-- **name**: Human-readable name
-- **description**: Brief description of the game type
-- **genre_tags**: Searchable tags
-- **fragment_file**: Path to type-specific template fragment
-
-### Game-Type Fragments
-
-Located in `game-types/` folder, these markdown files contain sections specific to each game type:
-
-**action-platformer.md**:
-
-- Movement System (jump mechanics, air control, special moves)
-- Combat System (attack types, combos, enemy AI)
-- Level Design Patterns (platforming challenges, combat arenas)
-- Player Abilities and Unlocks
-
-**rpg.md**:
-
-- Character System (stats, classes, leveling)
-- Inventory and Equipment
-- Quest System
-- World and Exploration
-- NPC and Dialogue
-- Combat System
-
-**puzzle.md**:
-
-- Core Puzzle Mechanics
-- Puzzle Progression
-- Level Structure
-- Player Assistance
-- Replayability
-
-**roguelike.md**:
-
-- Run Structure
-- Procedural Generation
-- Permadeath and Progression
-- Item and Upgrade System
-- Character Selection
-- Difficulty Modifiers
-
-...and 20+ more game types!
-
-## Workflow Flow
-
-1. **Router Detection** (instructions-router.md):
-   - Step 3 asks for project type
-   - If "Game" selected → sets `workflow_type = "gdd"`
-   - Skips standard level classification
-   - Jumps to GDD-specific assessment
-
-2. **Game Type Selection** (instructions-gdd.md Step 1):
-   - Presents 9 common game types + "Other"
-   - Maps selection to `game-types.csv`
-   - Loads corresponding fragment file
-   - Stores `game_type` for injection
-
-3. **Universal GDD Sections** (Steps 2-5, 7-13):
-   - Platform and target audience
-   - Goals and context
-   - Core gameplay (pillars, loop, win/loss)
-   - Mechanics and controls
-   - Progression and balance
-   - Level design
-   - Art and audio
-   - Technical specs
-   - Epics and metrics
-
-4. **Game-Type Injection** (Step 6):
-   - Loads fragment from `game-types/{game_type}.md`
-   - For each `{{placeholder}}` in fragment, elicits details
-   - Injects completed sections into `{{GAME_TYPE_SPECIFIC_SECTIONS}}`
-
-5. **Solutioning Handoff** (Step 14):
-   - Routes to `3-solutioning` workflow
-   - Platform/engine specifics handled by solutioning registry
-   - Game-\* entries in solutioning `registry.csv` provide engine-specific guidance
-
-## Platform vs. Game Type Separation
-
-**GDD (this workflow)**: Game-type specifics
-
-- What makes an RPG an RPG (stats, quests, inventory)
-- What makes a platformer a platformer (jump mechanics, level design)
-- Genre-defining mechanics and systems
-
-**Solutioning (3-solutioning workflow)**: Platform/engine specifics
-
-- Unity vs. Godot vs. Phaser vs. Unreal
-- 2D vs. 3D rendering
-- Physics engines
-- Input systems
-- Platform constraints (mobile, web, console)
-
-This separation allows:
-
-- Single universal GDD regardless of platform
-- Platform decisions made during architecture phase
-- Easy platform pivots without rewriting GDD
-
-## Output
-
-**GDD.md**: Complete game design document with:
-
-- All universal sections filled
-- Game-type-specific sections injected
-- Ready for solutioning handoff
-
-## Example Game Types
-
-| ID                | Name              | Key Sections                                      |
-| ----------------- | ----------------- | ------------------------------------------------- |
-| action-platformer | Action Platformer | Movement, Combat, Level Patterns, Abilities       |
-| rpg               | RPG               | Character System, Inventory, Quests, World, NPCs  |
-| puzzle            | Puzzle            | Puzzle Mechanics, Progression, Level Structure    |
-| roguelike         | Roguelike         | Run Structure, Procgen, Permadeath, Items         |
-| shooter           | Shooter           | Weapon Systems, Enemy AI, Arena Design            |
-| strategy          | Strategy          | Resources, Units, AI, Victory Conditions          |
-| metroidvania      | Metroidvania      | Interconnected World, Ability Gating, Exploration |
-| visual-novel      | Visual Novel      | Branching Story, Dialogue Trees, Choices          |
-| tower-defense     | Tower Defense     | Waves, Tower Types, Placement, Economy            |
-| card-game         | Card Game         | Deck Building, Card Mechanics, Turn System        |
-
-...and 14+ more!
-
-## Adding New Game Types
-
-1. Add row to `game-types.csv`:
-
-   ```csv
-   new-type,New Type Name,"Description",tags,new-type.md
-   ```
-
-2. Create `game-types/new-type.md`:
-
-   ```markdown
-   ## New Type Specific Elements
-
-   ### System Name
-
-   {{system_placeholder}}
-
-   **Details:**
-
-   - Element 1
-   - Element 2
-   ```
-
-3. The workflow automatically uses it!
-
-## Integration with Solutioning
-
-When a game project completes the GDD and moves to solutioning:
-
-1. Solutioning workflow reads `project_type == "game"`
-2. Loads GDD.md instead of PRD.md
-3. Matches game platforms to solutioning `registry.csv` game-\* entries
-4. Provides engine-specific guidance (Unity, Godot, Phaser, etc.)
-5. Generates architecture.md with platform decisions
-6. Creates per-epic tech specs
-
-Example solutioning registry entries:
-
-- `game-unity-2d`: Unity 2D games
-- `game-godot-3d`: Godot 3D games
-- `game-phaser`: Phaser web games
-- `game-unreal-3d`: Unreal Engine games
-- `game-custom-3d-rust`: Custom Rust game engines
-
-## Philosophy
-
-**Game projects are fundamentally different from software products**:
-
-- Gameplay feel > feature lists
-- Playtesting > user testing
-- Game pillars > product goals
-- Mechanics > requirements
-- Fun > utility
-
-The GDD workflow respects these differences while maintaining BMAD Method rigor.

package/src/modules/bmm/workflows/4-implementation/create-story/README.md

@@ -1,129 +0,0 @@
----
-last-redoc-date: 2025-10-01
----
-
-# Create Story Workflow
-
-The create-story workflow is the entry point for v6's just-in-time story generation approach, run exclusively by the Scrum Master (SM) agent. Unlike batch processing methodologies, this workflow generates exactly ONE story at a time based on the current epic backlog state, ensuring stories are created only when needed and with the most current context. The SM analyzes the epic's progress, identifies what needs to be built next based on epics.md enumeration, and generates a complete story specification including acceptance criteria, technical approach, and implementation guidance pulled directly from tech specs, PRD, and architecture documentation.
-
-This workflow represents a fundamental shift from traditional upfront planning to adaptive story generation. By creating stories one at a time and enforcing strict verification against epics.md, the SM ensures that only planned and approved stories are created. The workflow operates in non-interactive "#yolo" mode by default, minimizing prompts while maintaining quality through rigorous source document grounding. It will HALT if epics.md doesn't explicitly enumerate the next story, forcing proper planning through the correct-course workflow rather than allowing ad-hoc story creation.
-
-The workflow's intelligent document discovery system automatically finds the relevant tech spec for the current epic (using pattern `tech-spec-epic-{epic_num}-*.md`), loads all architecture documents from both docs/ and output folders, and synthesizes requirements from multiple sources in priority order. After story creation, it can optionally trigger the story-context workflow to generate just-in-time technical expertise for the developer.
-
-## Usage
-
-```bash
-# SM initiates story creation for the next piece of work
-bmad sm *create-story
-```
-
-The SM runs this workflow when:
-
-- The current sprint has capacity for new work
-- The previous story status is "Done" or "Approved"
-- The team is ready for the next planned story in the epic
-- Story preparation is needed before development
-
-## Inputs
-
-**Required Context Files:**
-
-- **epics.md**: MANDATORY - Must explicitly enumerate the next story or workflow halts
-- **tech-spec-epic-{N}-\*.md**: Epic-specific technical specification (auto-discovered)
-- **PRD.md**: Product requirements document (fallback for requirements)
-- **Architecture Documents**: Automatically discovered from docs/ and output folders:
-  - tech-stack.md, unified-project-structure.md, coding-standards.md
-  - testing-strategy.md, backend-architecture.md, frontend-architecture.md
-  - data-models.md, database-schema.md, rest-api-spec.md, external-apis.md
-
-**Workflow Variables:**
-
-- `story_dir`: From config `dev_story_location` - where stories are saved
-- `epic_num`: Current epic number (auto-detected from existing stories)
-- `story_num`: Next story number (incremented from last completed story)
-- `auto_run_context`: Default true - runs story-context workflow after creation
-- `non_interactive`: Default true - operates in "#yolo" mode with minimal prompts
-
-## Outputs
-
-**Primary Deliverable:**
-
-- **Story Document** (`{story_dir}/story-{epic_num}.{story_num}.md`): Complete story specification including:
-  - User story statement (role, action, benefit)
-  - Acceptance criteria extracted from tech spec or epics.md
-  - Tasks and subtasks mapped to ACs
-  - Testing requirements per testing strategy
-  - Dev notes with source citations
-  - Status: "Draft" (requires approval before development)
-
-**Validation Safeguards:**
-
-- **Epic Enumeration Check**: If epics.md doesn't list the next story, workflow HALTS with:
-  ```
-  "No planned next story found in epics.md for epic {epic_num}.
-  Please load either PM or SM agent and run *correct-course to add/modify epic stories."
-  ```
-- **Status Check**: Won't create new story if current story isn't Done/Approved
-- **Document Grounding**: All requirements traced to source documents (no invention)
-
-## Key Features
-
-**Strict Planning Enforcement**: The workflow will NOT create stories that aren't explicitly planned in epics.md. This prevents scope creep and ensures all work is properly approved through the planning process.
-
-**Intelligent Document Discovery**: Automatically finds the latest tech spec for the epic using glob patterns, discovers all architecture documents across multiple directories, and builds a prioritized document set for requirement extraction.
-
-**Source Document Grounding**: Every requirement, acceptance criterion, and technical constraint is traced to a specific source document. The workflow explicitly forbids inventing domain facts not present in source materials.
-
-**Non-Interactive by Default**: Operates in "#yolo" mode to minimize interruptions, only prompting when absolutely necessary (like missing critical configuration). This enables smooth automated story preparation.
-
-**Automatic Context Generation**: When `auto_run_context` is true (default), automatically triggers the story-context workflow to generate developer expertise injection for the newly created story.
-
-## Integration with v6 Flow
-
-The create-story workflow is step 1 in the v6 implementation cycle:
-
-1. **SM: create-story** ← You are here
-2. SM: story-context (adds JIT technical expertise)
-3. DEV: dev-story (implements with generated context)
-4. DEV/SR: code-review (validates completion)
-5. If needed: correct-course (adjusts direction)
-6. After epic: retrospective (captures learnings)
-
-This workflow establishes the "what" that needs to be built, strictly based on planned epics. The story-context workflow will later add the "how" through just-in-time technical expertise injection.
-
-## Document Priority Order
-
-The workflow uses this priority for extracting requirements:
-
-1. **tech_spec_file**: Epic-scoped technical specification (highest priority)
-2. **epics_file**: Acceptance criteria and story breakdown
-3. **prd_file**: Business requirements and constraints
-4. **Architecture docs**: Constraints, patterns, and technical guidance
-
-## Workflow Behavior
-
-**Story Number Management:**
-
-- Automatically detects next story number from existing files
-- Won't skip numbers or create duplicates
-- Maintains epic.story numbering convention
-
-**Update vs Create:**
-
-- If latest story status != Done/Approved: Updates existing story
-- If latest story status == Done/Approved: Creates next story (if enumerated in epics.md)
-
-**Epic Advancement:**
-
-- In non-interactive mode: Stays within current epic
-- Interactive mode: Can prompt for new epic number
-
-## Troubleshooting
-
-**"No planned next story found in epics.md"**: The next story isn't enumerated in epics.md. Run SM or PM agent's `*correct-course` to properly plan and add the story to the epic.
-
-**Missing story_dir Configuration**: Ensure `dev_story_location` is set in bmad/bmm/config.yaml
-
-**Tech Spec Not Found**: The workflow looks for `tech-spec-epic-{N}-*.md` pattern. Ensure tech specs follow this naming convention.
-
-**Architecture Documents Missing**: While not fatal, missing architecture docs reduce story context quality. Ensure key docs exist in docs/ or output folder.