bmad-fh 6.0.0-alpha.23

package/docs/downloads.md

@@ -0,0 +1,72 @@
+---
+title: Downloads
+---
+
+Download BMad Method resources for offline use, AI training, or integration.
+
+## Source Bundles
+
+| File | Description |
+|------|-------------|
+| **[bmad-sources.zip](/downloads/bmad-sources.zip)** | Complete BMad source files |
+| **[bmad-prompts.zip](/downloads/bmad-prompts.zip)** | Agent and workflow prompts only |
+
+## LLM-Optimized Files
+
+These files are designed for AI consumption - perfect for loading into Claude, ChatGPT, or any LLM context window.
+
+| File | Description | Use Case |
+|------|-------------|----------|
+| **[llms.txt](/llms.txt)** | Documentation index with summaries | Quick overview, navigation |
+| **[llms-full.txt](/llms-full.txt)** | Complete documentation concatenated | Full context loading |
+
+### Using with LLMs
+
+**Claude Projects:**
+```
+Upload llms-full.txt as project knowledge
+```
+
+**ChatGPT:**
+```
+Paste llms.txt for navigation, or sections from llms-full.txt as needed
+```
+
+**API Usage:**
+```python
+import requests
+docs = requests.get("https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt").text
+# Include in your system prompt or context
+```
+
+## Installation Options
+
+### NPM (Recommended)
+
+```bash
+npx bmad-method@alpha install
+```
+
+## Version Information
+
+- **Current Version:** See [CHANGELOG](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/CHANGELOG.md)
+- **Release Notes:** Available on [GitHub Releases](https://github.com/bmad-code-org/BMAD-METHOD/releases)
+
+## API Access
+
+For programmatic access to BMad documentation:
+
+```bash
+# Get documentation index
+curl https://bmad-code-org.github.io/BMAD-METHOD/llms.txt
+
+# Get full documentation
+curl https://bmad-code-org.github.io/BMAD-METHOD/llms-full.txt
+```
+
+## Contributing
+
+Want to improve BMad Method? Check out:
+
+- [Contributing Guide](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/CONTRIBUTING.md)
+- [GitHub Repository](https://github.com/bmad-code-org/BMAD-METHOD)

package/docs/explanation/agents/barry-quick-flow.md

@@ -0,0 +1,328 @@
+---
+title: "Quick Flow Solo Dev Agent (Barry)"
+---
+
+Barry is the elite solo developer who takes projects from concept to deployment with ruthless efficiency — no handoffs, no delays, just pure focused development.
+
+:::note[Agent Info]
+- **Agent ID:** `_bmad/bmm/agents/quick-flow-solo-dev.md`
+- **Icon:** 🚀
+- **Module:** BMM
+:::
+
+## Overview
+
+Barry is the elite solo developer who lives and breathes the BMad Quick Flow workflow. He takes projects from concept to deployment with ruthless efficiency - no handoffs, no delays, just pure focused development. Barry architects specs, writes the code, and ships features faster than entire teams. When you need it done right and done now, Barry's your dev.
+
+### Agent Persona
+
+**Name:** Barry
+**Title:** Quick Flow Solo Dev
+
+**Identity:** Barry is an elite developer who thrives on autonomous execution. He lives and breathes the BMad Quick Flow workflow, taking projects from concept to deployment with ruthless efficiency. No handoffs, no delays - just pure, focused development. He architects specs, writes the code, and ships features faster than entire teams.
+
+**Communication Style:** Direct, confident, and implementation-focused. Uses tech slang and gets straight to the point. No fluff, just results. Every response moves the project forward.
+
+**Core Principles:**
+
+- Planning and execution are two sides of the same coin
+- Quick Flow is my religion
+- Specs are for building, not bureaucracy
+- Code that ships is better than perfect code that doesn't
+- Documentation happens alongside development, not after
+- Ship early, ship often
+
+## Menu Commands
+
+Barry owns the entire BMad Quick Flow path, providing a streamlined 3-step development process that eliminates handoffs and maximizes velocity.
+
+### 1. **quick-spec**
+
+- **Workflow:** `_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md`
+- **Description:** Architect a technical spec with implementation-ready stories
+- **Use when:** You need to transform requirements into a buildable spec
+
+### 2. **quick-dev**
+
+- **Workflow:** `_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.yaml`
+- **Description:** Ship features from spec or direct instructions - no handoffs
+- **Use when:** You're ready to ship code based on a spec or clear instructions
+
+### 3. **code-review**
+
+- **Workflow:** `_bmad/bmm/workflows/4-implementation/code-review/workflow.yaml`
+- **Description:** Review code for quality, patterns, and acceptance criteria
+- **Use when:** You need to validate implementation quality
+
+### 4. **party-mode**
+
+- **Workflow:** `_bmad/core/workflows/party-mode/workflow.yaml`
+- **Description:** Bring in other experts when I need specialized backup
+- **Use when:** You need collaborative problem-solving or specialized expertise
+
+## When to Use Barry
+
+### Ideal Scenarios
+
+1. **Quick Flow Development** - Small to medium features that need rapid delivery
+2. **Technical Specification Creation** - When you need detailed implementation plans
+3. **Direct Development** - When requirements are clear and you want to skip extensive planning
+4. **Code Reviews** - When you need senior-level technical validation
+5. **Performance-Critical Features** - When optimization and scalability are paramount
+
+### Project Types
+
+- **Greenfield Projects** - New features or components
+- **Brownfield Modifications** - Enhancements to existing codebases
+- **Bug Fixes** - Complex issues requiring deep technical understanding
+- **Proof of Concepts** - Rapid prototyping with production-quality code
+- **Performance Optimizations** - System improvements and scalability work
+
+## The BMad Quick Flow Process
+
+Barry orchestrates a simple, efficient 3-step process:
+
+```mermaid
+flowchart LR
+    A[Requirements] --> B[quick-spec]
+    B --> C[Tech Spec]
+    C --> D[quick-dev]
+    D --> E[Implementation]
+    E --> F{Code Review?}
+    F -->|Yes| G[code-review]
+    F -->|No| H[Complete]
+    G --> H[Complete]
+
+    style A fill:#e1f5fe
+    style B fill:#f3e5f5
+    style C fill:#e8f5e9
+    style D fill:#fff3e0
+    style E fill:#fce4ec
+    style G fill:#f1f8e9
+    style H fill:#e0f2f1
+```
+
+### Step 1: Technical Specification (`quick-spec`)
+
+**Goal:** Transform user requirements into implementation-ready technical specifications
+
+**Process:**
+
+1. **Problem Understanding** - Clarify requirements, scope, and constraints
+2. **Code Investigation** - Analyze existing patterns and dependencies (if applicable)
+3. **Specification Generation** - Create comprehensive tech spec with:
+   - Problem statement and solution overview
+   - Development context and patterns
+   - Implementation tasks with acceptance criteria
+   - Technical decisions and dependencies
+4. **Review and Finalize** - Validate spec captures user intent
+
+**Output:** `tech-spec-{slug}.md` saved to sprint artifacts
+
+**Best Practices:**
+
+- Include ALL context a fresh dev agent needs
+- Be specific about files, patterns, and conventions
+- Define clear acceptance criteria using Given/When/Then format
+- Document technical decisions and trade-offs
+
+### Step 2: Development (`quick-dev`)
+
+**Goal:** Execute implementation based on tech spec or direct instructions
+
+**Two Modes:**
+
+**Mode A: Tech-Spec Driven**
+
+- Load existing tech spec
+- Extract tasks, context, and acceptance criteria
+- Execute all tasks continuously without stopping
+- Respect project context and existing patterns
+
+**Mode B: Direct Instructions**
+
+- Accept direct development commands
+- Offer optional planning step
+- Execute with minimal friction
+
+**Process:**
+
+1. **Load Project Context** - Understand patterns and conventions
+2. **Execute Implementation** - Work through all tasks:
+   - Load relevant files and context
+   - Implement following established patterns
+   - Write and run tests
+   - Handle errors appropriately
+3. **Verify Completion** - Ensure all tasks complete, tests passing, AC satisfied
+
+### Step 3: Code Review (`code-review`) - Optional
+
+**Goal:** Senior developer review of implemented code
+
+**When to Use:**
+
+- Critical production features
+- Complex architectural changes
+- Performance-sensitive implementations
+- Team development scenarios
+- Learning and knowledge transfer
+
+**Review Focus:**
+
+- Code quality and patterns
+- Acceptance criteria compliance
+- Performance and scalability
+- Security considerations
+- Maintainability and documentation
+
+## Collaboration with Other Agents
+
+### Natural Partnerships
+
+- **Tech Writer** - For documentation and API specs when I need it
+- **Architect** - For complex system design decisions beyond Quick Flow scope
+- **Dev** - For implementation pair programming (rarely needed)
+- **QA** - For test strategy and quality gates on critical features
+- **UX Designer** - For user experience considerations
+
+### Party Mode Composition
+
+In party mode, Barry often acts as:
+
+- **Solo Tech Lead** - Guiding architectural decisions
+- **Implementation Expert** - Providing coding insights
+- **Performance Optimizer** - Ensuring scalable solutions
+- **Code Review Authority** - Validating technical approaches
+
+## Tips for Working with Barry
+
+### For Best Results
+
+1. **Be Specific** - Provide clear requirements and constraints
+2. **Share Context** - Include relevant files and patterns
+3. **Define Success** - Clear acceptance criteria lead to better outcomes
+4. **Trust the Process** - The 3-step flow is optimized for speed and quality
+5. **Leverage Expertise** - I'll give you optimization and architectural insights automatically
+
+### Communication Patterns
+
+- **Git Commit Style** - "feat: Add user authentication with OAuth 2.0"
+- **RFC Style** - "Proposing microservice architecture for scalability"
+- **Direct Questions** - "Actually, have you considered the race condition?"
+- **Technical Trade-offs** - "We could optimize for speed over memory here"
+
+### Avoid These Common Mistakes
+
+1. **Vague Requirements** - Leads to unnecessary back-and-forth
+2. **Ignoring Patterns** - Causes technical debt and inconsistencies
+3. **Skipping Code Review** - Missed opportunities for quality improvement
+4. **Over-planning** - I excel at rapid, pragmatic development
+5. **Not Using Party Mode** - Missing collaborative insights for complex problems
+
+## Example Workflow
+
+```bash
+# Start with Barry
+/bmad:bmm:agents:quick-flow-solo-dev
+
+# Create a tech spec
+> quick-spec
+
+# Quick implementation
+> quick-dev tech-spec-auth.md
+
+# Optional code review
+> code-review
+```
+
+### Sample Tech Spec Structure
+
+```markdown
+# Tech-Spec: User Authentication System
+
+**Created:** 2025-01-15
+**Status:** Ready for Development
+
+## Overview
+
+### Problem Statement
+
+Users cannot securely access the application, and we need role-based permissions for enterprise features.
+
+### Solution
+
+Implement OAuth 2.0 authentication with JWT tokens and role-based access control (RBAC).
+
+### Scope (In/Out)
+
+**In:** Login, logout, password reset, role management
+**Out:** Social login, SSO, multi-factor authentication (Phase 2)
+
+## Context for Development
+
+### Codebase Patterns
+
+- Use existing auth middleware pattern in `src/middleware/auth.js`
+- Follow service layer pattern from `src/services/`
+- JWT secrets managed via environment variables
+
+### Files to Reference
+
+- `src/middleware/auth.js` - Authentication middleware
+- `src/models/User.js` - User data model
+- `config/database.js` - Database connection
+
+### Technical Decisions
+
+- JWT tokens over sessions for API scalability
+- bcrypt for password hashing
+- Role-based permissions stored in database
+
+## Implementation Plan
+
+### Tasks
+
+- [ ] Create authentication service
+- [ ] Implement login/logout endpoints
+- [ ] Add JWT middleware
+- [ ] Create role-based permissions
+- [ ] Write comprehensive tests
+
+### Acceptance Criteria
+
+- [ ] Given valid credentials, when user logs in, then receive JWT token
+- [ ] Given invalid token, when accessing protected route, then return 401
+- [ ] Given admin role, when accessing admin endpoint, then allow access
+```
+
+## Common Questions
+
+- [When should I use Barry vs other agents?](#when-should-i-use-barry-vs-other-agents)
+- [Is the code review step mandatory?](#is-the-code-review-step-mandatory)
+- [Can I skip the tech spec step?](#can-i-skip-the-tech-spec-step)
+- [How does Barry differ from the Dev agent?](#how-does-barry-differ-from-the-dev-agent)
+- [Can Barry handle enterprise-scale projects?](#can-barry-handle-enterprise-scale-projects)
+
+### When should I use Barry vs other agents?
+
+Use Barry for Quick Flow development (small to medium features), rapid prototyping, or when you need elite solo development. For large, complex projects requiring full team collaboration, consider the full BMad Method with specialized agents.
+
+### Is the code review step mandatory?
+
+No, it's optional but highly recommended for critical features, team projects, or when learning best practices.
+
+### Can I skip the tech spec step?
+
+Yes, the quick-dev workflow accepts direct instructions. However, tech specs are recommended for complex features or team collaboration.
+
+### How does Barry differ from the Dev agent?
+
+Barry handles the complete Quick Flow process (spec → dev → review) with elite architectural expertise, while the Dev agent specializes in pure implementation tasks. Barry is your autonomous end-to-end solution.
+
+### Can Barry handle enterprise-scale projects?
+
+For enterprise-scale projects requiring full team collaboration, consider using the Enterprise Method track. Barry is optimized for rapid delivery in the Quick Flow track where solo execution wins.
+
+:::tip[Ready to Ship?]
+Start with `/bmad:bmm:agents:quick-flow-solo-dev`
+:::

package/docs/explanation/agents/index.md

@@ -0,0 +1,19 @@
+---
+title: "Understanding Agents"
+description: Understanding BMad agents and their roles
+---
+
+Comprehensive guides to BMad's AI agents — their roles, capabilities, and how to work with them effectively.
+
+## Agent Guides
+
+| Agent                                                                           | Description                                          |
+| ------------------------------------------------------------------------------- | ---------------------------------------------------- |
+| **[Agent Roles](/docs/explanation/core-concepts/agent-roles.md)**               | Overview of all BMM agent roles and responsibilities |
+| **[Quick Flow Solo Dev (Barry)](/docs/explanation/agents/barry-quick-flow.md)** | The dedicated agent for rapid development            |
+
+## Getting Started
+
+1. Read **[What Are Agents?](/docs/explanation/core-concepts/what-are-agents.md)** for the core concept explanation
+2. Review **[Agent Roles](/docs/explanation/core-concepts/agent-roles.md)** to understand available agents
+3. Choose an agent that fits your workflow needs

package/docs/explanation/architecture/four-phases.md

@@ -0,0 +1,107 @@
+---
+title: "The Four Phases of BMad Method"
+description: Understanding the four phases of the BMad Method
+---
+
+
+BMad Method uses a four-phase approach that adapts to project complexity while ensuring consistent quality.
+
+## Phase Overview
+
+| Phase | Name | Purpose | Required? |
+|-------|------|---------|-----------|
+| **Phase 1** | Analysis | Exploration and discovery | Optional |
+| **Phase 2** | Planning | Requirements definition | Required |
+| **Phase 3** | Solutioning | Technical design | Track-dependent |
+| **Phase 4** | Implementation | Building the software | Required |
+
+## Phase 1: Analysis (Optional)
+
+Exploration and discovery workflows that help validate ideas and understand markets before planning.
+
+**Workflows:**
+- `brainstorm-project` - Solution exploration
+- `research` - Market/technical/competitive research
+- `product-brief` - Strategic vision capture
+
+**When to use:**
+- Starting new projects
+- Exploring opportunities
+- Validating market fit
+
+**When to skip:**
+- Clear requirements
+- Well-defined features
+- Continuing existing work
+
+## Phase 2: Planning (Required)
+
+Requirements definition using the scale-adaptive system to match planning depth to project complexity.
+
+**Workflows:**
+- `prd` - Product Requirements Document (BMad Method/Enterprise)
+- `tech-spec` - Technical specification (Quick Flow)
+- `create-ux-design` - Optional UX specification
+
+**Key principle:**
+Define **what** to build and **why**. Leave **how** to Phase 3.
+
+## Phase 3: Solutioning (Track-Dependent)
+
+Technical architecture and design decisions that prevent agent conflicts during implementation.
+
+**Workflows:**
+- `architecture` - System design with ADRs
+- `create-epics-and-stories` - Work breakdown (after architecture)
+- `implementation-readiness` - Gate check
+
+**Required for:**
+- BMad Method (complex projects)
+- Enterprise Method
+
+**Skip for:**
+- Quick Flow (simple changes)
+
+**Key principle:**
+Make technical decisions explicit so all agents implement consistently.
+
+## Phase 4: Implementation (Required)
+
+Iterative sprint-based development with story-centric workflow.
+
+**Workflows:**
+- `sprint-planning` - Initialize tracking
+- `create-story` - Prepare stories
+- `dev-story` - Implement with tests
+- `code-review` - Quality assurance
+- `retrospective` - Continuous improvement
+
+:::tip[Key Principle]
+One story at a time — complete each story's full lifecycle before starting the next.
+:::
+
+## Phase Flow by Track
+
+### Quick Flow
+
+```
+Phase 2 (tech-spec) → Phase 4 (implement)
+```
+
+Skip Phases 1 and 3 for simple changes.
+
+### BMad Method
+
+```
+Phase 1 (optional) → Phase 2 (PRD) → Phase 3 (architecture) → Phase 4 (implement)
+```
+
+Full methodology for complex projects.
+
+### Enterprise
+
+```
+Phase 1 → Phase 2 (PRD) → Phase 3 (architecture + extended) → Phase 4 (implement)
+```
+
+Same as BMad Method with optional extended workflows.

package/docs/explanation/architecture/preventing-agent-conflicts.md

@@ -0,0 +1,111 @@
+---
+title: "Preventing Agent Conflicts"
+description: How architecture prevents conflicts when multiple agents implement a system
+---
+
+
+When multiple AI agents implement different parts of a system, they can make conflicting technical decisions. Architecture documentation prevents this by establishing shared standards.
+
+## Common Conflict Types
+
+### API Style Conflicts
+
+Without architecture:
+- Agent A uses REST with `/users/{id}`
+- Agent B uses GraphQL mutations
+- Result: Inconsistent API patterns, confused consumers
+
+With architecture:
+- ADR specifies: "Use GraphQL for all client-server communication"
+- All agents follow the same pattern
+
+### Database Design Conflicts
+
+Without architecture:
+- Agent A uses snake_case column names
+- Agent B uses camelCase column names
+- Result: Inconsistent schema, confusing queries
+
+With architecture:
+- Standards document specifies naming conventions
+- All agents follow the same patterns
+
+### State Management Conflicts
+
+Without architecture:
+- Agent A uses Redux for global state
+- Agent B uses React Context
+- Result: Multiple state management approaches, complexity
+
+With architecture:
+- ADR specifies state management approach
+- All agents implement consistently
+
+## How Architecture Prevents Conflicts
+
+### 1. Explicit Decisions via ADRs
+
+Every significant technology choice is documented with:
+- Context (why this decision matters)
+- Options considered (what alternatives exist)
+- Decision (what we chose)
+- Rationale (why we chose it)
+- Consequences (trade-offs accepted)
+
+### 2. FR/NFR-Specific Guidance
+
+Architecture maps each functional requirement to technical approach:
+- FR-001: User Management → GraphQL mutations
+- FR-002: Mobile App → Optimized queries
+
+### 3. Standards and Conventions
+
+Explicit documentation of:
+- Directory structure
+- Naming conventions
+- Code organization
+- Testing patterns
+
+## Architecture as Shared Context
+
+Think of architecture as the shared context that all agents read before implementing:
+
+```
+PRD: "What to build"
+     ↓
+Architecture: "How to build it"
+     ↓
+Agent A reads architecture → implements Epic 1
+Agent B reads architecture → implements Epic 2
+Agent C reads architecture → implements Epic 3
+     ↓
+Result: Consistent implementation
+```
+
+## Key ADR Topics
+
+Common decisions that prevent conflicts:
+
+| Topic | Example Decision |
+|-------|-----------------|
+| API Style | GraphQL vs REST vs gRPC |
+| Database | PostgreSQL vs MongoDB |
+| Auth | JWT vs Sessions |
+| State Management | Redux vs Context vs Zustand |
+| Styling | CSS Modules vs Tailwind vs Styled Components |
+| Testing | Jest + Playwright vs Vitest + Cypress |
+
+## Anti-Patterns to Avoid
+
+:::caution[Common Mistakes]
+- **Implicit Decisions** — "We'll figure out the API style as we go" leads to inconsistency
+- **Over-Documentation** — Documenting every minor choice causes analysis paralysis
+- **Stale Architecture** — Documents written once and never updated cause agents to follow outdated patterns
+:::
+
+:::tip[Correct Approach]
+- Document decisions that cross epic boundaries
+- Focus on conflict-prone areas
+- Update architecture as you learn
+- Use `correct-course` for significant changes
+:::