bmad-method 4.13.0 → 4.14.1

package/dist/agents/bmad-master.txt

@@ -1333,385 +1333,313 @@ Generate comprehensive documentation for existing projects optimized for AI deve
 
 ### 1. Initial Project Analysis
 
-[[LLM: Begin by conducting a comprehensive analysis of the existing project. Use available tools to:
+[[LLM: First, check if a PRD or requirements document exists in context. If yes, use it to focus your documentation efforts on relevant areas only.
 
-1. **Project Structure Discovery**: Examine the root directory structure, identify main folders, and understand the overall organization
-2. **Technology Stack Identification**: Look for package.json, requirements.txt, Cargo.toml, pom.xml, etc. to identify languages, frameworks, and dependencies
-3. **Build System Analysis**: Find build scripts, CI/CD configurations, and development commands
-4. **Existing Documentation Review**: Check for README files, docs folders, and any existing documentation
-5. **Code Pattern Analysis**: Sample key files to understand coding patterns, naming conventions, and architectural approaches
-
-Ask the user these elicitation questions to better understand their needs:
-
-- What is the primary purpose of this project?
-- Are there any specific areas of the codebase that are particularly complex or important for agents to understand?
-- What types of tasks do you expect AI agents to perform on this project? (e.g., bug fixes, feature additions, refactoring, testing)
-- Are there any existing documentation standards or formats you prefer?
-- What level of technical detail should the documentation target? (junior developers, senior developers, mixed team)
-  ]]
-
-### 2. Core Documentation Generation
-
-[[LLM: Based on your analysis, generate the following core documentation files. Adapt the content and structure to match the specific project type and context you discovered:
-
-**Core Documents (always generate):**
-
-1. **docs/index.md** - Master documentation index
-2. **docs/architecture/index.md** - Architecture documentation index
-3. **docs/architecture/coding-standards.md** - Coding conventions and style guidelines
-4. **docs/architecture/tech-stack.md** - Technology stack and version constraints
-5. **docs/architecture/unified-project-structure.md** - Project structure and organization
-6. **docs/architecture/testing-strategy.md** - Testing approaches and requirements
-
-**Backend Documents (generate for backend/full-stack projects):**
-
-7. **docs/architecture/backend-architecture.md** - Backend service patterns and structure
-8. **docs/architecture/rest-api-spec.md** - API endpoint specifications
-9. **docs/architecture/data-models.md** - Data structures and validation rules
-10. **docs/architecture/database-schema.md** - Database design and relationships
-11. **docs/architecture/external-apis.md** - Third-party integrations
-
-**Frontend Documents (generate for frontend/full-stack projects):**
-
-12. **docs/architecture/frontend-architecture.md** - Frontend patterns and structure
-13. **docs/architecture/components.md** - UI component specifications
-14. **docs/architecture/core-workflows.md** - User interaction flows
-15. **docs/architecture/ui-ux-spec.md** - UI/UX specifications and guidelines
-
-**Additional Documents (generate if applicable):**
-
-16. **docs/prd.md** - Product requirements document (if not exists)
-17. **docs/architecture/deployment-guide.md** - Deployment and operations info
-18. **docs/architecture/security-considerations.md** - Security patterns and requirements
-19. **docs/architecture/performance-guidelines.md** - Performance optimization patterns
-
-**Optional Enhancement Documents:**
-
-20. **docs/architecture/troubleshooting-guide.md** - Common issues and solutions
-21. **docs/architecture/changelog-conventions.md** - Change management practices
-22. **docs/architecture/code-review-checklist.md** - Review standards and practices
-
-Present each document section by section, using the advanced elicitation task after each major section.]]
-
-### 3. Document Structure Template
-
-[[LLM: Use this standardized structure for each documentation file, adapting content as needed:
-
-```markdown
-# {{Document Title}}
-
-## Overview
-
-{{Brief description of what this document covers and why it's important for AI agents}}
+**IF PRD EXISTS**: 
 
-## Quick Reference
+- Review the PRD to understand what enhancement/feature is planned
+- Identify which modules, services, or areas will be affected
+- Focus documentation ONLY on these relevant areas
+- Skip unrelated parts of the codebase to keep docs lean
 
-{{Key points, commands, or patterns that agents need most frequently}}
+**IF NO PRD EXISTS**:
+Ask the user:
 
-## Detailed Information
+"I notice you haven't provided a PRD or requirements document. To create more focused and useful documentation, I recommend one of these options:
 
-{{Comprehensive information organized into logical sections}}
+1. **Create a PRD first** - Would you like me to help create a brownfield PRD before documenting? This helps focus documentation on relevant areas.
 
-## Examples
+2. **Provide existing requirements** - Do you have a requirements document, epic, or feature description you can share?
 
-{{Concrete examples showing proper usage or implementation}}
+3. **Describe the focus** - Can you briefly describe what enhancement or feature you're planning? For example:
+   - 'Adding payment processing to the user service'
+   - 'Refactoring the authentication module'
+   - 'Integrating with a new third-party API'
 
-## Common Patterns
+4. **Document everything** - Or should I proceed with comprehensive documentation of the entire codebase? (Note: This may create excessive documentation for large projects)
 
-{{Recurring patterns agents should recognize and follow}}
+Please let me know your preference, or I can proceed with full documentation if you prefer."
 
-## Things to Avoid
+Based on their response:
 
-{{Anti-patterns, deprecated approaches, or common mistakes}}
+- If they choose option 1-3: Use that context to focus documentation
+- If they choose option 4 or decline: Proceed with comprehensive analysis below
 
-## Related Resources
+Begin by conducting analysis of the existing project. Use available tools to:
 
-{{Links to other relevant documentation or external resources}}
-```
+1. **Project Structure Discovery**: Examine the root directory structure, identify main folders, and understand the overall organization
+2. **Technology Stack Identification**: Look for package.json, requirements.txt, Cargo.toml, pom.xml, etc. to identify languages, frameworks, and dependencies
+3. **Build System Analysis**: Find build scripts, CI/CD configurations, and development commands
+4. **Existing Documentation Review**: Check for README files, docs folders, and any existing documentation
+5. **Code Pattern Analysis**: Sample key files to understand coding patterns, naming conventions, and architectural approaches
 
-Each document should be:
+Ask the user these elicitation questions to better understand their needs:
 
-- **Concrete and actionable** - Focus on what agents need to do, not just concepts
-- **Pattern-focused** - Highlight recurring patterns agents can recognize and replicate
-- **Example-rich** - Include specific code examples and real file references
-- **Context-aware** - Reference actual project files, folders, and conventions
-- **Assumption-free** - Don't assume agents know project history or implicit knowledge
+- What is the primary purpose of this project?
+- Are there any specific areas of the codebase that are particularly complex or important for agents to understand?
+- What types of tasks do you expect AI agents to perform on this project? (e.g., bug fixes, feature additions, refactoring, testing)
+- Are there any existing documentation standards or formats you prefer?
+- What level of technical detail should the documentation target? (junior developers, senior developers, mixed team)
+- Is there a specific feature or enhancement you're planning? (This helps focus documentation)
   ]]
 
-### 4. Content Guidelines for Each Document Type
-
-#### Core Architecture Documents
-
-##### docs/architecture/index.md
-
-[[LLM: Create a comprehensive index of all architecture documentation:
-
-- List all architecture documents with brief descriptions
-- Group documents by category (backend, frontend, shared)
-- Include quick links to key sections
-- Provide reading order recommendations for different use cases]]
-
-##### docs/architecture/unified-project-structure.md
+### 2. Deep Codebase Analysis
 
-[[LLM: Document the complete project structure:
+[[LLM: Before generating documentation, conduct extensive analysis of the existing codebase:
 
-- Root-level directory structure with explanations
-- Where each type of code belongs (backend, frontend, tests, etc.)
-- File naming conventions and patterns
-- Module/package organization
-- Generated vs. source file locations
-- Build output locations]]
+1. **Explore Key Areas**:
+   - Entry points (main files, index files, app initializers)
+   - Configuration files and environment setup
+   - Package dependencies and versions
+   - Build and deployment configurations
+   - Test suites and coverage
 
-##### docs/architecture/coding-standards.md
+2. **Ask Clarifying Questions**:
+   - "I see you're using [technology X]. Are there any custom patterns or conventions I should document?"
+   - "What are the most critical/complex parts of this system that developers struggle with?"
+   - "Are there any undocumented 'tribal knowledge' areas I should capture?"
+   - "What technical debt or known issues should I document?"
+   - "Which parts of the codebase change most frequently?"
 
-[[LLM: Capture project-wide coding conventions:
+3. **Map the Reality**:
+   - Identify ACTUAL patterns used (not theoretical best practices)
+   - Find where key business logic lives
+   - Locate integration points and external dependencies
+   - Document workarounds and technical debt
+   - Note areas that differ from standard patterns
 
-- Language-specific style guidelines
-- Naming conventions (variables, functions, classes, files)
-- Code organization within files
-- Import/export patterns
-- Comment and documentation standards
-- Linting and formatting tool configurations
-- Git commit message conventions]]
+**IF PRD PROVIDED**: Also analyze what would need to change for the enhancement]]
 
-##### docs/architecture/tech-stack.md
+### 3. Core Documentation Generation
 
-[[LLM: Document all technologies and versions:
+[[LLM: Generate a comprehensive BROWNFIELD architecture document that reflects the ACTUAL state of the codebase.
 
-- Primary languages and versions
-- Frameworks and major libraries with versions
-- Development tools and their versions
-- Database systems and versions
-- External services and APIs used
-- Browser/runtime requirements]]
+**CRITICAL**: This is NOT an aspirational architecture document. Document what EXISTS, including:
+- Technical debt and workarounds
+- Inconsistent patterns between different parts
+- Legacy code that can't be changed
+- Integration constraints
+- Performance bottlenecks
 
-##### docs/architecture/testing-strategy.md
+**Document Structure**:
 
-[[LLM: Define testing approaches and requirements:
+# [Project Name] Brownfield Architecture Document
 
-- Test file locations and naming conventions
-- Unit testing patterns and frameworks
-- Integration testing approaches
-- E2E testing setup (if applicable)
-- Test coverage requirements
-- Mocking strategies
-- Test data management]]
-
-#### Backend Architecture Documents
-
-##### docs/architecture/backend-architecture.md
-
-[[LLM: Document backend service structure:
-
-- Service layer organization
-- Controller/route patterns
-- Middleware architecture
-- Authentication/authorization patterns
-- Request/response flow
-- Background job processing
-- Service communication patterns]]
-
-##### docs/architecture/rest-api-spec.md
-
-[[LLM: Specify all API endpoints:
-
-- Base URL and versioning strategy
-- Authentication methods
-- Common headers and parameters
-- Each endpoint with:
-  - HTTP method and path
-  - Request parameters/body
-  - Response format and status codes
-  - Error responses
-- Rate limiting and quotas]]
-
-##### docs/architecture/data-models.md
-
-[[LLM: Define data structures and validation:
-
-- Core business entities
-- Data validation rules
-- Relationships between entities
-- Computed fields and derivations
-- Data transformation patterns
-- Serialization formats]]
-
-##### docs/architecture/database-schema.md
-
-[[LLM: Document database design:
-
-- Database type and version
-- Table/collection structures
-- Indexes and constraints
-- Relationships and foreign keys
-- Migration patterns
-- Seed data requirements
-- Backup and recovery procedures]]
-
-##### docs/architecture/external-apis.md
-
-[[LLM: Document third-party integrations:
-
-- List of external services used
-- Authentication methods for each
-- API endpoints and usage patterns
-- Rate limits and quotas
-- Error handling strategies
-- Webhook configurations
-- Data synchronization patterns]]
+## Introduction
+This document captures the CURRENT STATE of the [Project Name] codebase, including technical debt, workarounds, and real-world patterns. It serves as a reference for AI agents working on enhancements.
 
-#### Frontend Architecture Documents
+### Document Scope
+[If PRD provided: "Focused on areas relevant to: {enhancement description}"]
+[If no PRD: "Comprehensive documentation of entire system"]
 
-##### docs/architecture/frontend-architecture.md
+### Change Log
+| Date | Version | Description | Author |
+|------|---------|-------------|--------|
+| [Date] | 1.0 | Initial brownfield analysis | [Analyst] |
 
-[[LLM: Document frontend application structure:
+## Quick Reference - Key Files and Entry Points
 
-- Component hierarchy and organization
-- State management patterns
-- Routing architecture
-- Data fetching patterns
-- Authentication flow
-- Error boundary strategies
-- Performance optimization patterns]]
+### Critical Files for Understanding the System
+- **Main Entry**: `src/index.js` (or actual entry point)
+- **Configuration**: `config/app.config.js`, `.env.example`
+- **Core Business Logic**: `src/services/`, `src/domain/`
+- **API Definitions**: `src/routes/` or link to OpenAPI spec
+- **Database Models**: `src/models/` or link to schema files
+- **Key Algorithms**: [List specific files with complex logic]
 
-##### docs/architecture/components.md
+### If PRD Provided - Enhancement Impact Areas
+[Highlight which files/modules will be affected by the planned enhancement]
 
-[[LLM: Specify UI components:
+## High Level Architecture
 
-- Component library/design system used
-- Custom component specifications
-- Props and state for each component
-- Component composition patterns
-- Styling approaches
-- Accessibility requirements
-- Component testing patterns]]
+### Technical Summary
+[Real assessment of architecture - mention if it's well-structured or has issues]
 
-##### docs/architecture/core-workflows.md
+### Actual Tech Stack (from package.json/requirements.txt)
+| Category | Technology | Version | Notes |
+|----------|------------|---------|--------|
+| Runtime | Node.js | 16.x | [Any constraints] |
+| Framework | Express | 4.18.2 | [Custom middleware?] |
+| Database | PostgreSQL | 13 | [Connection pooling setup] |
+| [etc...] |
 
-[[LLM: Document user interaction flows:
+### Repository Structure Reality Check
+- Type: [Monorepo/Polyrepo/Hybrid]
+- Package Manager: [npm/yarn/pnpm]
+- Notable: [Any unusual structure decisions]
 
-- Major user journeys
-- Screen flow diagrams
-- Form handling patterns
-- Navigation patterns
-- Data flow through workflows
-- Error states and recovery
-- Loading and transition states]]
+## Source Tree and Module Organization
 
-##### docs/architecture/ui-ux-spec.md
+### Project Structure (Actual)
+```
+project-root/
+├── src/
+│   ├── controllers/     # HTTP request handlers
+│   ├── services/        # Business logic (NOTE: inconsistent patterns between user and payment services)
+│   ├── models/          # Database models (Sequelize)
+│   ├── utils/           # Mixed bag - needs refactoring
+│   └── legacy/          # DO NOT MODIFY - old payment system still in use
+├── tests/               # Jest tests (60% coverage)
+├── scripts/             # Build and deployment scripts
+└── config/              # Environment configs
+```
 
-[[LLM: Define UI/UX guidelines:
+### Key Modules and Their Purpose
+- **User Management**: `src/services/userService.js` - Handles all user operations
+- **Authentication**: `src/middleware/auth.js` - JWT-based, custom implementation
+- **Payment Processing**: `src/legacy/payment.js` - CRITICAL: Do not refactor, tightly coupled
+- **[List other key modules with their actual files]**
 
-- Design system specifications
-- Color palette and typography
-- Spacing and layout grids
-- Responsive breakpoints
-- Animation and transition guidelines
-- Accessibility standards
-- Browser compatibility requirements]]
+## Data Models and APIs
 
-### 5. Adaptive Content Strategy
+### Data Models
+Instead of duplicating, reference actual model files:
+- **User Model**: See `src/models/User.js`
+- **Order Model**: See `src/models/Order.js`
+- **Related Types**: TypeScript definitions in `src/types/`
 
-[[LLM: Adapt your documentation approach based on project characteristics:
+### API Specifications
+- **OpenAPI Spec**: `docs/api/openapi.yaml` (if exists)
+- **Postman Collection**: `docs/api/postman-collection.json`
+- **Manual Endpoints**: [List any undocumented endpoints discovered]
 
-**For Web Applications:**
+## Technical Debt and Known Issues
 
-- Focus on component patterns, routing, state management
-- Include build processes, asset handling, and deployment
-- Cover API integration patterns and data fetching
+### Critical Technical Debt
+1. **Payment Service**: Legacy code in `src/legacy/payment.js` - tightly coupled, no tests
+2. **User Service**: Different pattern than other services, uses callbacks instead of promises
+3. **Database Migrations**: Manually tracked, no proper migration tool
+4. **[Other significant debt]**
 
-**For Backend Services:**
+### Workarounds and Gotchas
+- **Environment Variables**: Must set `NODE_ENV=production` even for staging (historical reason)
+- **Database Connections**: Connection pool hardcoded to 10, changing breaks payment service
+- **[Other workarounds developers need to know]**
 
-- Emphasize service architecture, data models, and API design
-- Include database interaction patterns and migration strategies
-- Cover authentication, authorization, and security patterns
+## Integration Points and External Dependencies
 
-**For CLI Tools:**
+### External Services
+| Service | Purpose | Integration Type | Key Files |
+|---------|---------|------------------|-----------|
+| Stripe | Payments | REST API | `src/integrations/stripe/` |
+| SendGrid | Emails | SDK | `src/services/emailService.js` |
+| [etc...] |
 
-- Focus on command structure, argument parsing, and output formatting
-- Include plugin/extension patterns if applicable
-- Cover configuration file handling and user interaction patterns
+### Internal Integration Points
+- **Frontend Communication**: REST API on port 3000, expects specific headers
+- **Background Jobs**: Redis queue, see `src/workers/`
+- **[Other integrations]**
 
-**For Libraries/Frameworks:**
+## Development and Deployment
 
-- Emphasize public API design and usage patterns
-- Include extension points and customization approaches
-- Cover versioning, compatibility, and migration strategies
+### Local Development Setup
+1. Actual steps that work (not ideal steps)
+2. Known issues with setup
+3. Required environment variables (see `.env.example`)
 
-**For Mobile Applications:**
+### Build and Deployment Process
+- **Build Command**: `npm run build` (webpack config in `webpack.config.js`)
+- **Deployment**: Manual deployment via `scripts/deploy.sh`
+- **Environments**: Dev, Staging, Prod (see `config/environments/`)
 
-- Focus on platform-specific patterns and navigation
-- Include state management and data persistence approaches
-- Cover platform integration and native feature usage
+## Testing Reality
 
-**For Data Science/ML Projects:**
+### Current Test Coverage
+- Unit Tests: 60% coverage (Jest)
+- Integration Tests: Minimal, in `tests/integration/`
+- E2E Tests: None
+- Manual Testing: Primary QA method
 
-- Emphasize data pipeline patterns and model organization
-- Include experiment tracking and reproducibility approaches
-- Cover data validation and model deployment patterns
-  ]]
+### Running Tests
+```bash
+npm test           # Runs unit tests
+npm run test:integration  # Runs integration tests (requires local DB)
+```
 
-### 6. Quality Assurance
+## If Enhancement PRD Provided - Impact Analysis
 
-[[LLM: Before completing each document:
+### Files That Will Need Modification
+Based on the enhancement requirements, these files will be affected:
+- `src/services/userService.js` - Add new user fields
+- `src/models/User.js` - Update schema
+- `src/routes/userRoutes.js` - New endpoints
+- [etc...]
 
-1. **Accuracy Check**: Verify all file paths, commands, and code examples work
-2. **Completeness Review**: Ensure the document covers the most important patterns an agent would encounter
-3. **Clarity Assessment**: Check that explanations are clear and actionable
-4. **Consistency Verification**: Ensure terminology and patterns align across all documents
-5. **Agent Perspective**: Review from the viewpoint of an AI agent that needs to contribute to this project
+### New Files/Modules Needed
+- `src/services/newFeatureService.js` - New business logic
+- `src/models/NewFeature.js` - New data model
+- [etc...]
 
-Ask the user to review each completed document and use the advanced elicitation task to refine based on their feedback.]]
+### Integration Considerations
+- Will need to integrate with existing auth middleware
+- Must follow existing response format in `src/utils/responseFormatter.js`
+- [Other integration points]
 
-### 7. Final Integration
+## Appendix - Useful Commands and Scripts
 
-[[LLM: After all documents are completed:
+### Frequently Used Commands
+```bash
+npm run dev         # Start development server
+npm run build       # Production build
+npm run migrate     # Run database migrations
+npm run seed        # Seed test data
+```
 
-1. Ensure all documents are created in the proper BMAD-expected locations:
+### Debugging and Troubleshooting
+- **Logs**: Check `logs/app.log` for application logs
+- **Debug Mode**: Set `DEBUG=app:*` for verbose logging
+- **Common Issues**: See `docs/troubleshooting.md`]]
 
-   - Core docs in `docs/` (index.md, prd.md)
-   - Architecture shards in `docs/architecture/` subdirectory
-   - Create the `docs/architecture/` directory if it doesn't exist
+### 4. Document Delivery
 
-2. Create/update the master index documents:
+[[LLM: After generating the complete architecture document:
 
-   - Update `docs/index.md` to reference all documentation
-   - Create `docs/architecture/index.md` listing all architecture shards
+1. **In Web UI (Gemini, ChatGPT, Claude)**:
+   - Present the entire document in one response (or multiple if too long)
+   - Tell user to copy and save as `docs/brownfield-architecture.md` or `docs/project-architecture.md`
+   - Mention it can be sharded later in IDE if needed
 
-3. Verify document cross-references:
+2. **In IDE Environment**:
+   - Create the document as `docs/brownfield-architecture.md`
+   - Inform user this single document contains all architectural information
+   - Can be sharded later using PO agent if desired
 
-   - Ensure all documents link to related documentation
-   - Check that file paths match the actual project structure
-   - Validate that examples reference real files in the project
+The document should be comprehensive enough that future agents can understand:
+- The actual state of the system (not idealized)
+- Where to find key files and logic
+- What technical debt exists
+- What constraints must be respected
+- If PRD provided: What needs to change for the enhancement]]
 
-4. Provide maintenance guidance:
+### 5. Quality Assurance
 
-   - Document update triggers (when to update each doc)
-   - Create a simple checklist for keeping docs current
-   - Suggest automated validation approaches
+[[LLM: Before finalizing the document:
 
-5. Summary report including:
-   - List of all documents created with their paths
-   - Any gaps or areas needing human review
-   - Recommendations for project-specific additions
-   - Next steps for maintaining documentation accuracy
+1. **Accuracy Check**: Verify all technical details match the actual codebase
+2. **Completeness Review**: Ensure all major system components are documented
+3. **Focus Validation**: If user provided scope, verify relevant areas are emphasized
+4. **Clarity Assessment**: Check that explanations are clear for AI agents
+5. **Navigation**: Ensure document has clear section structure for easy reference
 
-Present a summary of what was created and ask if any additional documentation would be helpful for AI agents working on this specific project.]]
+Apply the advanced elicitation task after major sections to refine based on user feedback.]]
 
 ## Success Criteria
 
-- Documentation enables AI agents to understand project context without additional explanation
-- All major architectural patterns and coding conventions are captured
-- Examples reference actual project files and demonstrate real usage
-- Documentation is structured consistently and easy to navigate
-- Content is actionable and focuses on what agents need to do, not just understand
+- Single comprehensive brownfield architecture document created
+- Document reflects REALITY including technical debt and workarounds
+- Key files and modules are referenced with actual paths
+- Models/APIs reference source files rather than duplicating content
+- If PRD provided: Clear impact analysis showing what needs to change
+- Document enables AI agents to navigate and understand the actual codebase
+- Technical constraints and "gotchas" are clearly documented
 
 ## Notes
 
-- This task is designed to work with any project type, language, or framework
-- The documentation should reflect the project as it actually is, not as it should be
-- Focus on patterns that agents can recognize and replicate consistently
-- Include both positive examples (what to do) and negative examples (what to avoid)
+- This task creates ONE document that captures the TRUE state of the system
+- References actual files rather than duplicating content when possible
+- Documents technical debt, workarounds, and constraints honestly
+- For brownfield projects with PRD: Provides clear enhancement impact analysis
+- The goal is PRACTICAL documentation for AI agents doing real work
 ==================== END: tasks#document-project ====================
 
 ==================== START: tasks#create-next-story ====================
@@ -2314,9 +2242,27 @@ Would you like to proceed with documentation indexing? Please provide the requir
 - Create a folder structure to organize the sharded documents
 - Maintain all content integrity including code blocks, diagrams, and markdown formatting
 
-## Recommended Method: @kayvan/markdown-tree-parser
+## Primary Method: Automatic with markdown-tree
+
+[[LLM: First, check if markdownExploder is set to true in bmad-core/core-config.yml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
+
+If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
+
+If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
+
+1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
+2. Or set markdownExploder to false in bmad-core/core-config.yml
 
-[[LLM: First, suggest the user install and use the @kayvan/markdown-tree-parser tool if the md-tree command is unavailable so we can have the best performance and reliable document sharding. Let the user know this will save cost of having the LLM to the expensive sharding operation. Give instructions for MPV NPX and PNPM global installs.]]
+**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
+
+If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
+
+1. Set markdownExploder to true in bmad-core/core-config.yml
+2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
+
+I will now proceed with the manual sharding process."
+
+Then proceed with the manual method below ONLY if markdownExploder is false.]]
 
 ### Installation and Usage
 
@@ -2349,19 +2295,19 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
 
 ---
 
-## Manual Method (if @kayvan/markdown-tree-parser is not available)
+## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
 
 [[LLM: Only proceed with the manual instructions below if the user cannot or does not want to use @kayvan/markdown-tree-parser.]]
 
 ### Task Instructions
 
-### 1. Identify Document and Target Location
+1. Identify Document and Target Location
 
 - Determine which document to shard (user-provided path)
 - Create a new folder under `docs/` with the same name as the document (without extension)
 - Example: `docs/prd.md` → create folder `docs/prd/`
 
-### 2. Parse and Extract Sections
+2. Parse and Extract Sections
 
 [[LLM: When sharding the document:
 
@@ -2371,7 +2317,7 @@ If the user has @kayvan/markdown-tree-parser installed, use it and skip the manu
    - Extract the section heading and ALL content until the next level 2 section
    - Include all subsections, code blocks, diagrams, lists, tables, etc.
    - Be extremely careful with:
-     - Fenced code blocks (```) - ensure you capture the full block including closing backticks
+     - Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
      - Mermaid diagrams - preserve the complete diagram syntax
      - Nested markdown elements
      - Multi-line content that might contain ## inside code blocks
@@ -2390,7 +2336,7 @@ For each extracted section:
 
 2. **Adjust heading levels**:
 
-   - The level 2 heading becomes level 1 (# instead of ##)
+   - The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
    - All subsection levels decrease by 1:
 
    ```txt
@@ -6720,6 +6666,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
 [[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update - remove this line to the SM]]
 [[LLM: (Dev Agent) Anything the SM needs to know that deviated from the story that might impact drafting the next story.]]
 
+### File List
+
+[[LLM: (Dev Agent) List every new file created, or existing file modified in a bullet list.]]
+
 ### Change Log
 
 [[LLM: (SM Agent) When Drafting Story, leave next prompt in place for dev agent to remove and update- remove this line to the SM]]
@@ -6727,6 +6677,10 @@ Manual Test Steps: [[LLM: Include how if possible the user can manually test the
 
 | Date | Version | Description | Author |
 | :--- | :------ | :---------- | :----- |
+
+## QA Results
+
+[[LLM: QA Agent Results]]
 ==================== END: templates#story-tmpl ====================
 
 ==================== START: checklists#architect-checklist ====================
@@ -8468,6 +8422,50 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
 - **Quality Assurance**: Structured testing and validation
 - **Documentation**: Professional PRDs, architecture docs, user stories
 
+## How BMAD Works
+
+### The Core Method
+
+BMAD transforms you into a "Vibe CEO" - directing a team of specialized AI agents through structured workflows. Here's how:
+
+1. **You Direct, AI Executes**: You provide vision and decisions; agents handle implementation details
+2. **Specialized Agents**: Each agent masters one role (PM, Developer, Architect, etc.)
+3. **Structured Workflows**: Proven patterns guide you from idea to deployed code
+4. **Clean Handoffs**: Fresh context windows ensure agents stay focused and effective
+
+### The Two-Phase Approach
+
+**Phase 1: Planning (Web UI - Cost Effective)**
+- Use large context windows (Gemini's 1M tokens)
+- Generate comprehensive documents (PRD, Architecture)
+- Leverage multiple agents for brainstorming
+- Create once, use throughout development
+
+**Phase 2: Development (IDE - Implementation)**
+- Shard documents into manageable pieces
+- Execute focused SM → Dev cycles
+- One story at a time, sequential progress
+- Real-time file operations and testing
+
+### The Development Loop
+
+```text
+1. SM Agent (New Chat) → Creates next story from sharded docs
+2. You → Review and approve story
+3. Dev Agent (New Chat) → Implements approved story
+4. QA Agent (New Chat) → Reviews and refactors code
+5. You → Verify completion
+6. Repeat until epic complete
+```
+
+### Why This Works
+
+- **Context Optimization**: Clean chats = better AI performance
+- **Role Clarity**: Agents don't context-switch = higher quality
+- **Incremental Progress**: Small stories = manageable complexity
+- **Human Oversight**: You validate each step = quality control
+- **Document-Driven**: Specs guide everything = consistency
+
 ## Getting Started
 
 ### Quick Start Options
@@ -8482,7 +8480,7 @@ BMAD-METHOD (Breakthrough Method of Agile AI-driven Development) is a framework
 5. Type `/help` to see available commands
 
 #### Option 2: IDE Integration
-**Best for**: Cursor, Claude Code, Windsurf, VS Code users
+**Best for**: Cursor, Claude Code, Windsurf, Cline, Roo Code users
 
 ```bash
 # Interactive installation (recommended)
@@ -8491,13 +8489,22 @@ npx bmad-method install
 
 **Installation Steps**:
 - Choose "Complete installation"
-- Select your IDE (Cursor, Claude Code, Windsurf, or Roo Code)
+- Select your IDE from supported options:
+  - **Cursor**: Native AI integration
+  - **Claude Code**: Anthropic's official IDE
+  - **Windsurf**: Built-in AI capabilities
+  - **Cline**: VS Code extension with AI features
+  - **Roo Code**: Web-based IDE with agent support
+
+**Note for VS Code Users**: BMAD-METHOD assumes when you mention "VS Code" that you're using it with an AI-powered extension like GitHub Copilot, Cline, or Roo. Standard VS Code without AI capabilities cannot run BMAD agents. The installer includes built-in support for Cline and Roo.
 
 **Verify Installation**:
 - `.bmad-core/` folder created with all agents
 - IDE-specific integration files created
 - All agent commands/rules/modes available
 
+**Remember**: At its core, BMAD-METHOD is about mastering and harnessing prompt engineering. Any IDE with AI agent support can use BMAD - the framework provides the structured prompts and workflows that make AI development effective
+
 ### Environment Selection Guide
 
 **Use Web UI for**:
@@ -8514,6 +8521,47 @@ npx bmad-method install
 
 **Cost-Saving Tip**: Create large documents (PRDs, architecture) in web UI, then copy to `docs/prd.md` and `docs/architecture.md` in your project before switching to IDE for development.
 
+### IDE-Only Workflow Considerations
+
+**Can you do everything in IDE?** Yes, but understand the tradeoffs:
+
+**Pros of IDE-Only**:
+- Single environment workflow
+- Direct file operations from start
+- No copy/paste between environments
+- Immediate project integration
+
+**Cons of IDE-Only**:
+- Higher token costs for large document creation
+- Smaller context windows (varies by IDE/model)
+- May hit limits during planning phases
+- Less cost-effective for brainstorming
+
+**Using Web Agents in IDE**:
+- **NOT RECOMMENDED**: Web agents (PM, Architect) have rich dependencies designed for large contexts
+- **Why it matters**: Dev agents are kept lean to maximize coding context
+- **The principle**: "Dev agents code, planning agents plan" - mixing breaks this optimization
+
+**About bmad-master and bmad-orchestrator**:
+- **bmad-master**: CAN do any task without switching agents, BUT...
+- **Still use specialized agents for planning**: PM, Architect, and UX Expert have tuned personas that produce better results
+- **Why specialization matters**: Each agent's personality and focus creates higher quality outputs
+- **If using bmad-master/orchestrator**: Fine for planning phases, but...
+
+**CRITICAL RULE for Development**:
+- **ALWAYS use SM agent for story creation** - Never use bmad-master/orchestrator
+- **ALWAYS use Dev agent for implementation** - Never use bmad-master/orchestrator
+- **Why this matters**: SM and Dev agents are specifically optimized for the development workflow
+- **No exceptions**: Even if using bmad-master for everything else, switch to SM → Dev for implementation
+
+**Best Practice for IDE-Only**:
+1. Use PM/Architect/UX agents for planning (better than bmad-master)
+2. Create documents directly in project
+3. Shard immediately after creation
+4. **MUST switch to SM agent** for story creation
+5. **MUST switch to Dev agent** for implementation
+6. Keep planning and coding in separate chat sessions
+
 ## Core Configuration (core-config.yml)
 
 **New in V4**: The `bmad-core/core-config.yml` file is a critical innovation that enables BMAD to work seamlessly with any project structure, providing maximum flexibility and backwards compatibility.
@@ -8754,10 +8802,16 @@ This architecture enables seamless operation across environments while maintaini
 
 ## Complete Development Workflow
 
-### Planning Phase (Web UI Recommended)
+### Planning Phase (Web UI Recommended - Especially Gemini!)
 
-**Ideal for cost efficiency, especially with Gemini:**
+**Ideal for cost efficiency with Gemini's massive context:**
 
+**For Brownfield Projects - Start Here!**:
+1. **Upload entire project to Gemini Web** (GitHub URL, files, or zip)
+2. **Document existing system**: `/analyst` → `*document-project`
+3. **Creates comprehensive docs** from entire codebase analysis
+
+**For All Projects**:
 1. **Optional Analysis**: `/analyst` - Market research, competitive analysis
 2. **Project Brief**: Create foundation document (Analyst or user)
 3. **PRD Creation**: `/pm create-doc prd` - Comprehensive product requirements
@@ -8791,10 +8845,14 @@ that can handle [specific requirements]."
 
 **Prerequisites**: Planning documents must exist in `docs/` folder
 
-1. **Document Sharding**: 
-   - `@bmad-master` or `@po` shard `docs/prd.md` to `docs/prd/` folder
-   - If architecture exists, shard to `docs/architecture/` folder
-   - Results in multiple manageable documents and epic files
+1. **Document Sharding** (CRITICAL STEP): 
+   - Documents created by PM/Architect (in Web or IDE) MUST be sharded for development
+   - Two methods to shard:
+     a) **Manual**: Drag `shard-doc` task + document file into chat
+     b) **Agent**: Ask `@bmad-master` or `@po` to shard documents
+   - Shards `docs/prd.md` → `docs/prd/` folder
+   - Shards `docs/architecture.md` → `docs/architecture/` folder
+   - **WARNING**: Do NOT shard in Web UI - copying many small files is painful!
 
 2. **Verify Sharded Content**:
    - At least one `epic-n.md` file in `docs/prd/` with stories in development order
@@ -8808,19 +8866,34 @@ that can handle [specific requirements]."
 
 3. **Development Cycle** (Sequential, one story at a time):
 
-   **Step 1 - Story Creation**: New chat window → `@sm` → `*create`
+   **CRITICAL CONTEXT MANAGEMENT**:
+   - **Context windows matter!** Always use fresh, clean context windows
+   - **Model selection matters!** Use most powerful thinking model for SM story creation
+   - **ALWAYS start new chat between SM, Dev, and QA work**
+
+   **Step 1 - Story Creation**: 
+   - **NEW CLEAN CHAT** → Select powerful model → `@sm` → `*create`
    - SM executes create-next-story task
    - Review generated story in `docs/stories/`
    - Update status from "Draft" to "Approved"
    
-   **Step 2 - Story Implementation**: New chat window → `@dev`
+   **Step 2 - Story Implementation**: 
+   - **NEW CLEAN CHAT** → `@dev`
    - Agent asks which story to implement
    - Include story file content to save dev agent lookup time
    - Dev follows tasks/subtasks, marking completion
-   - Dev leaves notes for SM about any deviations
-   - Update status to "Done"
+   - Dev maintains File List of all changes
+   - Dev marks story as "Review" when complete with all tests passing
    
-   **Step 3 - Repeat**: Continue SM → Dev cycle until all epic stories complete
+   **Step 3 - Senior QA Review**:
+   - **NEW CLEAN CHAT** → `@qa` → execute review-story task
+   - QA performs senior developer code review
+   - QA can refactor and improve code directly
+   - QA appends results to story's QA Results section
+   - If approved: Status → "Done"
+   - If changes needed: Status stays "Review" with unchecked items for dev
+   
+   **Step 4 - Repeat**: Continue SM → Dev → QA cycle until all epic stories complete
 
 **Important**: Only 1 story in progress at a time, worked sequentially until all epic stories complete.
 
@@ -8840,12 +8913,72 @@ Each status change requires user verification and approval before proceeding.
 - Development execution
 - Testing and deployment
 
-#### Brownfield Enhancement
-- Current system analysis
-- Enhancement planning
-- Impact assessment
-- Incremental development
-- Integration testing
+#### Brownfield Enhancement (Existing Projects)
+
+**Key Concept**: Brownfield development requires comprehensive documentation of your existing project for AI agents to understand context, patterns, and constraints.
+
+**Complete Brownfield Workflow Options**:
+
+**Option 1: PRD-First (Recommended for Large Codebases/Monorepos)**:
+1. **Upload project to Gemini Web** (GitHub URL, files, or zip)
+2. **Create PRD first**: `@pm` → `*create-doc brownfield-prd`
+3. **Focused documentation**: `@analyst` → `*document-project`
+   - Analyst asks for focus if no PRD provided
+   - Choose "single document" format for Web UI
+   - Uses PRD to document ONLY relevant areas
+   - Creates one comprehensive markdown file
+   - Avoids bloating docs with unused code
+
+**Option 2: Document-First (Good for Smaller Projects)**:
+1. **Upload project to Gemini Web**
+2. **Document everything**: `@analyst` → `*document-project`
+3. **Then create PRD**: `@pm` → `*create-doc brownfield-prd`
+   - More thorough but can create excessive documentation
+
+2. **Requirements Gathering**:
+   - **Brownfield PRD**: Use PM agent with `brownfield-prd-tmpl`
+   - **Analyzes**: Existing system, constraints, integration points
+   - **Defines**: Enhancement scope, compatibility requirements, risk assessment
+   - **Creates**: Epic and story structure for changes
+
+3. **Architecture Planning**:
+   - **Brownfield Architecture**: Use Architect agent with `brownfield-architecture-tmpl`
+   - **Integration Strategy**: How new features integrate with existing system
+   - **Migration Planning**: Gradual rollout and backwards compatibility
+   - **Risk Mitigation**: Addressing potential breaking changes
+
+**Brownfield-Specific Resources**:
+
+**Templates**:
+- `brownfield-prd-tmpl.md`: Comprehensive enhancement planning with existing system analysis
+- `brownfield-architecture-tmpl.md`: Integration-focused architecture for existing systems
+
+**Tasks**:
+- `document-project`: Generates comprehensive documentation from existing codebase
+- `brownfield-create-epic`: Creates single epic for focused enhancements (when full PRD is overkill)
+- `brownfield-create-story`: Creates individual story for small, isolated changes
+
+**When to Use Each Approach**:
+
+**Full Brownfield Workflow** (Recommended for):
+- Major feature additions
+- System modernization
+- Complex integrations
+- Multiple related changes
+
+**Quick Epic/Story Creation** (Use when):
+- Single, focused enhancement
+- Isolated bug fixes
+- Small feature additions
+- Well-documented existing system
+
+**Critical Success Factors**:
+1. **Documentation First**: Always run `document-project` if docs are outdated/missing
+2. **Context Matters**: Provide agents access to relevant code sections
+3. **Integration Focus**: Emphasize compatibility and non-breaking changes
+4. **Incremental Approach**: Plan for gradual rollout and testing
+
+**For detailed guide**: See `docs/working-in-the-brownfield.md`
 
 ## Document Creation Best Practices
 
@@ -8926,12 +9059,94 @@ Use the `shard-doc` task or `@kayvan/markdown-tree-parser` tool for automatic sh
 - **Keep conversations focused** - One agent, one task per conversation
 - **Review everything** - Always review and approve before marking complete
 
+## Contributing to BMAD-METHOD
+
+### Quick Contribution Guidelines
+
+For full details, see `CONTRIBUTING.md`. Key points:
+
+**Fork Workflow**:
+1. Fork the repository
+2. Create feature branches
+3. Submit PRs to `next` branch (default) or `main` for critical fixes only
+4. Keep PRs small: 200-400 lines ideal, 800 lines maximum
+5. One feature/fix per PR
+
+**PR Requirements**:
+- Clear descriptions (max 200 words) with What/Why/How/Testing
+- Use conventional commits (feat:, fix:, docs:)
+- Atomic commits - one logical change per commit
+- Must align with guiding principles
+
+**Core Principles** (from GUIDING-PRINCIPLES.md):
+- **Dev Agents Must Be Lean**: Minimize dependencies, save context for code
+- **Natural Language First**: Everything in markdown, no code in core
+- **Core vs Expansion Packs**: Core for universal needs, packs for specialized domains
+- **Design Philosophy**: "Dev agents code, planning agents plan"
+
+## Expansion Packs
+
+### What Are Expansion Packs?
+
+Expansion packs extend BMAD-METHOD beyond traditional software development into ANY domain. They provide specialized agent teams, templates, and workflows while keeping the core framework lean and focused on development.
+
+### Why Use Expansion Packs?
+
+1. **Keep Core Lean**: Dev agents maintain maximum context for coding
+2. **Domain Expertise**: Deep, specialized knowledge without bloating core
+3. **Community Innovation**: Anyone can create and share packs
+4. **Modular Design**: Install only what you need
+
+### Available Expansion Packs
+
+**Technical Packs**:
+- **Infrastructure/DevOps**: Cloud architects, SRE experts, security specialists
+- **Game Development**: Game designers, level designers, narrative writers
+- **Mobile Development**: iOS/Android specialists, mobile UX experts
+- **Data Science**: ML engineers, data scientists, visualization experts
+
+**Non-Technical Packs**:
+- **Business Strategy**: Consultants, financial analysts, marketing strategists
+- **Creative Writing**: Plot architects, character developers, world builders
+- **Health & Wellness**: Fitness trainers, nutritionists, habit engineers
+- **Education**: Curriculum designers, assessment specialists
+- **Legal Support**: Contract analysts, compliance checkers
+
+**Specialty Packs**:
+- **Expansion Creator**: Tools to build your own expansion packs
+- **RPG Game Master**: Tabletop gaming assistance
+- **Life Event Planning**: Wedding planners, event coordinators
+- **Scientific Research**: Literature reviewers, methodology designers
+
+### Using Expansion Packs
+
+1. **Browse Available Packs**: Check `expansion-packs/` directory
+2. **Get Inspiration**: See `docs/expansion-pack-ideas.md` for detailed examples
+3. **Install via CLI**: 
+   ```bash
+   npx bmad-method install
+   # Select "Install expansion pack" option
+   ```
+4. **Use in Your Workflow**: Installed packs integrate seamlessly with existing agents
+
+### Creating Custom Expansion Packs
+
+Use the **expansion-creator** pack to build your own:
+
+1. **Define Domain**: What expertise are you capturing?
+2. **Design Agents**: Create specialized roles with clear boundaries
+3. **Build Resources**: Tasks, templates, checklists for your domain
+4. **Test & Share**: Validate with real use cases, share with community
+
+**Key Principle**: Expansion packs democratize expertise by making specialized knowledge accessible through AI agents.
+
 ## Getting Help
 
 - **Commands**: Use `/help` in any environment to see available commands
 - **Agent Switching**: Use `/switch agent-name` with orchestrator for role changes
 - **Documentation**: Check `docs/` folder for project-specific context
 - **Community**: Discord and GitHub resources available for support
+- **Contributing**: See `CONTRIBUTING.md` for full guidelines
 ==================== END: data#bmad-kb ====================
 
 ==================== START: data#technical-preferences ====================