bmad-elsabro 1.0.0

package/docs/downloads.md

@@ -0,0 +1,74 @@
+---
+title: Downloads
+---
+
+Download BMad Method resources for offline use, AI training, or integration.
+
+## Source Bundles
+
+Download these from the `downloads/` folder on the documentation site.
+
+| File               | Description                     |
+| ------------------ | ------------------------------- |
+| `bmad-sources.zip` | Complete BMad source files      |
+| `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. See [API Access](#api-access) below for URLs.
+
+| File            | Description                         | Use Case                   |
+| --------------- | ----------------------------------- | -------------------------- |
+| `llms.txt`      | Documentation index with summaries  | Quick overview, navigation |
+| `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
+
+```bash
+npx bmad-method install
+```
+
+[More details](/docs/how-to/install-bmad.md)
+
+## 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/advanced-elicitation.md

@@ -0,0 +1,24 @@
+---
+title: "Advanced Elicitation"
+description: Push the LLM to rethink its work using structured reasoning methods
+---
+
+Make the LLM reconsider what it just generated. You pick a reasoning method, it applies that method to its own output, you decide whether to keep the improvements.
+
+Dozens of methods are built in - things like First Principles, Red Team vs Blue Team, Pre-mortem Analysis, Socratic Questioning, and more.
+
+## When to Use It
+
+- After a workflow generates content and you want alternatives
+- When output seems okay but you suspect there's more depth
+- To stress-test assumptions or find weaknesses
+- For high-stakes content where rethinking helps
+
+Workflows offer advanced elicitation at decision points - after the LLM has generated something, you'll be asked if you want to run it.
+
+## How It Works
+
+1. LLM suggests 5 relevant methods for your content
+2. You pick one (or reshuffle for different options)
+3. Method is applied, improvements shown
+4. Accept or discard, repeat or continue

package/docs/explanation/adversarial-review.md

@@ -0,0 +1,57 @@
+---
+title: "Adversarial Review"
+description: Forced reasoning technique that prevents lazy "looks good" reviews
+---
+
+Force deeper analysis by requiring problems to be found.
+
+## What is Adversarial Review?
+
+A review technique where the reviewer *must* find issues. No "looks good" allowed. The reviewer adopts a cynical stance - assume problems exist and find them.
+
+This isn't about being negative. It's about forcing genuine analysis instead of a cursory glance that rubber-stamps whatever was submitted.
+
+**The core rule:** You must find issues. Zero findings triggers a halt - re-analyze or explain why.
+
+## Why It Works
+
+Normal reviews suffer from confirmation bias. You skim the work, nothing jumps out, you approve it. The "find problems" mandate breaks this pattern:
+
+- **Forces thoroughness** - Can't approve until you've looked hard enough to find issues
+- **Catches missing things** - "What's not here?" becomes a natural question
+- **Improves signal quality** - Findings are specific and actionable, not vague concerns
+- **Information asymmetry** - Run reviews with fresh context (no access to original reasoning) so you evaluate the artifact, not the intent
+
+## Where It's Used
+
+Adversarial review appears throughout BMAD workflows - code review, implementation readiness checks, spec validation, and others. Sometimes it's a required step, sometimes optional (like advanced elicitation or party mode). The pattern adapts to whatever artifact needs scrutiny.
+
+## Human Filtering Required
+
+Because the AI is *instructed* to find problems, it will find problems - even when they don't exist. Expect false positives: nitpicks dressed as issues, misunderstandings of intent, or outright hallucinated concerns.
+
+**You decide what's real.** Review each finding, dismiss the noise, fix what matters.
+
+## Example
+
+Instead of:
+
+> "The authentication implementation looks reasonable. Approved."
+
+An adversarial review produces:
+
+> 1. **HIGH** - `login.ts:47` - No rate limiting on failed attempts
+> 2. **HIGH** - Session token stored in localStorage (XSS vulnerable)
+> 3. **MEDIUM** - Password validation happens client-side only
+> 4. **MEDIUM** - No audit logging for failed login attempts
+> 5. **LOW** - Magic number `3600` should be `SESSION_TIMEOUT_SECONDS`
+
+The first review might miss a security vulnerability. The second caught four.
+
+## Iteration and Diminishing Returns
+
+After addressing findings, consider running it again. A second pass usually catches more. A third isn't always useless either. But each pass takes time, and eventually you hit diminishing returns - just nitpicks and false findings.
+
+:::tip[Better Reviews]
+Assume problems exist. Look for what's missing, not just what's wrong.
+:::

package/docs/explanation/brainstorming.md

@@ -0,0 +1,31 @@
+---
+title: "Brainstorming"
+description: Interactive creative sessions using 60+ proven ideation techniques
+---
+
+Unlock your creativity through guided exploration.
+
+## What is Brainstorming?
+
+Run `brainstorming` and you've got a creative facilitator pulling ideas out of you - not generating them for you. The AI acts as coach and guide, using proven techniques to create conditions where your best thinking emerges.
+
+**Good for:**
+
+- Breaking through creative blocks
+- Generating product or feature ideas
+- Exploring problems from new angles
+- Developing raw concepts into action plans
+
+## How It Works
+
+1. **Setup** - Define topic, goals, constraints
+2. **Choose approach** - Pick techniques yourself, get AI recommendations, go random, or follow a progressive flow
+3. **Facilitation** - Work through techniques with probing questions and collaborative coaching
+4. **Organize** - Ideas grouped into themes and prioritized
+5. **Action** - Top ideas get next steps and success metrics
+
+Everything gets captured in a session document you can reference later or share with stakeholders.
+
+:::note[Your Ideas]
+Every idea comes from you. The workflow creates conditions for insight - you're the source.
+:::

package/docs/explanation/brownfield-faq.md

@@ -0,0 +1,55 @@
+---
+title: "Brownfield Development FAQ"
+description: Common questions about brownfield development in the BMad Method
+---
+Quick answers to common questions about brownfield (existing codebase) development in the BMad Method (BMM).
+
+## Questions
+
+- [Questions](#questions)
+  - [What is brownfield vs greenfield?](#what-is-brownfield-vs-greenfield)
+  - [Do I have to run document-project for brownfield?](#do-i-have-to-run-document-project-for-brownfield)
+  - [What if I forget to run document-project?](#what-if-i-forget-to-run-document-project)
+  - [Can I use Quick Spec Flow for brownfield projects?](#can-i-use-quick-spec-flow-for-brownfield-projects)
+  - [What if my existing code doesn't follow best practices?](#what-if-my-existing-code-doesnt-follow-best-practices)
+
+### What is brownfield vs greenfield?
+
+- **Greenfield** — New project, starting from scratch, clean slate
+- **Brownfield** — Existing project, working with established codebase and patterns
+
+### Do I have to run document-project for brownfield?
+
+Highly recommended, especially if:
+
+- No existing documentation
+- Documentation is outdated
+- AI agents need context about existing code
+
+You can skip it if you have comprehensive, up-to-date documentation including `docs/index.md` or will use other tools or techniques to aid in discovery for the agent to build on an existing system.
+
+### What if I forget to run document-project?
+
+Don't worry about it - you can do it at any time. You can even do it during or after a project to help keep docs up to date.
+
+### Can I use Quick Spec Flow for brownfield projects?
+
+Yes! Quick Spec Flow works great for brownfield. It will:
+
+- Auto-detect your existing stack
+- Analyze brownfield code patterns
+- Detect conventions and ask for confirmation
+- Generate context-rich tech-spec that respects existing code
+
+Perfect for bug fixes and small features in existing codebases.
+
+### What if my existing code doesn't follow best practices?
+
+Quick Spec Flow detects your conventions and asks: "Should I follow these existing conventions?" You decide:
+
+- **Yes** → Maintain consistency with current codebase
+- **No** → Establish new standards (document why in tech-spec)
+
+BMM respects your choice — it won't force modernization, but it will offer it.
+
+**Have a question not answered here?** Please [open an issue](https://github.com/bmad-code-org/BMAD-METHOD/issues) or ask in [Discord](https://discord.gg/gk8jAdXWmj) so we can add it!

package/docs/explanation/party-mode.md

@@ -0,0 +1,57 @@
+---
+title: "Party Mode"
+description: Multi-agent collaboration - get all your AI agents in one conversation
+---
+
+Get all your AI agents in one conversation.
+
+## What is Party Mode?
+
+Run `party-mode` and you've got your whole AI team in one room - PM, Architect, Dev, UX Designer, whoever you need. BMad Master orchestrates, picking relevant agents per message. Agents respond in character, agree, disagree, and build on each other's ideas.
+
+The conversation continues as long as you want. Ask follow-ups, push back on answers, redirect the discussion - it's a real back-and-forth with your agents until you're done.
+
+**Good for:**
+
+- Big decisions with tradeoffs
+- Brainstorming sessions
+- Post-mortems when things go wrong
+- Sprint retrospectives and planning
+
+## Examples
+
+### Calling Out Bad Architecture
+
+**You:** "Okay team, our last sprint was a disaster. The authentication service went down three times. Who screwed this up?"
+
+**Architect:** "The design was sound - distributed authentication with proper fallbacks. If implementation deviated from the spec..."
+
+**Dev:** "I followed the architecture doc exactly. The spec didn't account for concurrent session invalidation race conditions."
+
+**PM:** "Both of you missed the bigger issue - we didn't validate session management requirements in the PRD. This is on me for not catching it."
+
+**TEA:** "And I should've caught this in integration tests. The test scenarios didn't cover concurrent invalidation."
+
+### Creative Brainstorming
+
+**You:** "How do we make onboarding feel magical instead of boring?"
+
+**UX Designer:** "Start with progressive disclosure - reveal features as users need them, not all at once in a tutorial."
+
+**Storyteller:** "What if onboarding was a story? Each step reveals a character's journey - the user IS the hero."
+
+**Game Designer:** "Building on that - what if the first 'quest' is actually solving a real user problem? They learn by doing something valuable."
+
+### Technical Decision
+
+**You:** "Monolith or microservices for MVP?"
+
+**Architect:** "Start monolith. Microservices add complexity you don't need at 1000 users."
+
+**PM:** "Agree. Time to market matters more than theoretical scalability."
+
+**Dev:** "Monolith with clear module boundaries. We can extract services later if needed."
+
+:::tip[Better Decisions]
+Better decisions through diverse perspectives. Welcome to party mode.
+:::

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

@@ -0,0 +1,110 @@
+---
+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
+:::

package/docs/explanation/quick-flow.md

@@ -0,0 +1,27 @@
+---
+title: "Quick Flow"
+description: Fast-track for small changes - skip the full methodology
+---
+
+Quick Flow is for when you don't need the full BMad Method. Skip Product Brief, PRD, and Architecture - go straight to implementation.
+
+## How It Works
+
+1. **Run `quick-spec`** — generates a focused tech-spec
+2. **Run `quick-dev`** — implements it
+
+That's it.
+
+## When to Use It
+
+- Bug fixes
+- Refactoring
+- Small features
+- Prototyping
+
+## When to Use Full BMad Method Instead
+
+- New products
+- Major features
+- Multiple teams involved
+- Stakeholder alignment needed

package/docs/explanation/why-solutioning-matters.md

@@ -0,0 +1,75 @@
+---
+title: "Why Solutioning Matters"
+description: Understanding why the solutioning phase is critical for multi-epic projects
+---
+
+
+Phase 3 (Solutioning) translates **what** to build (from Planning) into **how** to build it (technical design). This phase prevents agent conflicts in multi-epic projects by documenting architectural decisions before implementation begins.
+
+## The Problem Without Solutioning
+
+```
+Agent 1 implements Epic 1 using REST API
+Agent 2 implements Epic 2 using GraphQL
+Result: Inconsistent API design, integration nightmare
+```
+
+When multiple agents implement different parts of a system without shared architectural guidance, they make independent technical decisions that may conflict.
+
+## The Solution With Solutioning
+
+```
+architecture workflow decides: "Use GraphQL for all APIs"
+All agents follow architecture decisions
+Result: Consistent implementation, no conflicts
+```
+
+By documenting technical decisions explicitly, all agents implement consistently and integration becomes straightforward.
+
+## Solutioning vs Planning
+
+| Aspect   | Planning (Phase 2)      | Solutioning (Phase 3)             |
+| -------- | ----------------------- | --------------------------------- |
+| Question | What and Why?           | How? Then What units of work?     |
+| Output   | FRs/NFRs (Requirements) | Architecture + Epics/Stories      |
+| Agent    | PM                      | Architect → PM                    |
+| Audience | Stakeholders            | Developers                        |
+| Document | PRD (FRs/NFRs)          | Architecture + Epic Files         |
+| Level    | Business logic          | Technical design + Work breakdown |
+
+## Key Principle
+
+**Make technical decisions explicit and documented** so all agents implement consistently.
+
+This prevents:
+- API style conflicts (REST vs GraphQL)
+- Database design inconsistencies
+- State management disagreements
+- Naming convention mismatches
+- Security approach variations
+
+## When Solutioning is Required
+
+| Track | Solutioning Required? |
+|-------|----------------------|
+| Quick Flow | No - skip entirely |
+| BMad Method Simple | Optional |
+| BMad Method Complex | Yes |
+| Enterprise | Yes |
+
+:::tip[Rule of Thumb]
+If you have multiple epics that could be implemented by different agents, you need solutioning.
+:::
+
+## The Cost of Skipping
+
+Skipping solutioning on complex projects leads to:
+
+- **Integration issues** discovered mid-sprint
+- **Rework** due to conflicting implementations
+- **Longer development time** overall
+- **Technical debt** from inconsistent patterns
+
+:::caution[Cost Multiplier]
+Catching alignment issues in solutioning is 10× faster than discovering them during implementation.
+:::

package/docs/how-to/brownfield/index.md

@@ -0,0 +1,84 @@
+---
+title: "Brownfield Development"
+description: How to use BMad Method on existing codebases
+---
+
+Use BMad Method effectively when working on existing projects and legacy codebases.
+
+## What is Brownfield Development?
+
+**Brownfield** refers to working on existing projects with established codebases and patterns, as opposed to **greenfield** which means starting from scratch with a clean slate.
+
+This guide covers the essential workflow for onboarding to brownfield projects with BMad Method.
+
+:::note[Prerequisites]
+- BMad Method installed (`npx bmad-method install`)
+- An existing codebase you want to work on
+- Access to an AI-powered IDE (Claude Code, Cursor, or Windsurf)
+:::
+
+## Step 1: Clean Up Completed Planning Artifacts
+
+If you have completed all PRD epics and stories through the BMad process, clean up those files. Archive them, delete them, or rely on version history if needed. Do not keep these files in:
+
+- `docs/`
+- `_bmad-output/planning-artifacts/`
+- `_bmad-output/implementation-artifacts/`
+
+## Step 2: Maintain Quality Project Documentation
+
+Your `docs/` folder should contain succinct, well-organized documentation that accurately represents your project:
+
+- Intent and business rationale
+- Business rules
+- Architecture
+- Any other relevant project information
+
+For complex projects, consider using the `document-project` workflow. It offers runtime variants that will scan your entire project and document its actual current state.
+
+## Step 3: Get Help
+
+Get help to know what to do next based on your unique needs
+
+Run `bmad-help` to get guidance when you are not sure what to do next.
+
+### Choosing Your Approach
+
+You have two primary options depending on the scope of changes:
+
+| Scope                          | Recommended Approach                                                                                                          |
+| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
+| **Small updates or additions** | Use `quick-flow-solo-dev` to create a tech-spec and implement the change. The full four-phase BMad method is likely overkill. |
+| **Major changes or additions** | Start with the BMad method, applying as much or as little rigor as needed.                                                    |
+
+### During PRD Creation
+
+When creating a brief or jumping directly into the PRD, ensure the agent:
+
+- Finds and analyzes your existing project documentation
+- Reads the proper context about your current system
+
+You can guide the agent explicitly, but the goal is to ensure the new feature integrates well with your existing system.
+
+### UX Considerations
+
+UX work is optional. The decision depends not on whether your project has a UX, but on:
+
+- Whether you will be working on UX changes
+- Whether significant new UX designs or patterns are needed
+
+If your changes amount to simple updates to existing screens you are happy with, a full UX process is unnecessary.
+
+### Architecture Considerations
+
+When doing architecture, ensure the architect:
+
+- Uses the proper documented files
+- Scans the existing codebase
+
+Pay close attention here to prevent reinventing the wheel or making decisions that misalign with your existing architecture.
+
+## More Information
+
+- **[Quick Fix in Brownfield](/docs/how-to/brownfield/quick-fix-in-brownfield.md)** - Bug fixes and ad-hoc changes
+- **[Brownfield FAQ](/docs/explanation/brownfield-faq.md)** - Common questions about brownfield development

package/docs/how-to/brownfield/quick-fix-in-brownfield.md

@@ -0,0 +1,76 @@
+---
+title: "How to Make Quick Fixes in Brownfield Projects"
+description: How to make quick fixes and ad-hoc changes in brownfield projects
+---
+
+Use the **DEV agent** directly for bug fixes, refactorings, or small targeted changes that don't require the full BMad method or Quick Flow.
+
+## When to Use This
+
+- Simple bug fixes
+- Small refactorings and changes that don't need extensive ideation, planning, or architectural shifts
+- Larger refactorings or improvement with built in tool planning and execution mode combination, or better yet use quick flow
+- Learning about your codebase
+
+## Steps
+
+### 1. Load an Agent
+
+For quick fixes, you can use:
+
+- **DEV agent** - For implementation-focused work
+- **Quick Flow Solo Dev** - For slightly larger changes that still need a quick-spec to keep the agent aligned to planning and standards
+
+### 2. Describe the Change
+
+Simply tell the agent what you need:
+
+```
+Fix the login validation bug that allows empty passwords
+```
+
+or
+
+```
+Refactor the UserService to use async/await instead of callbacks
+```
+
+### 3. Let the Agent Work
+
+The agent will:
+
+- Analyze the relevant code
+- Propose a solution
+- Implement the change
+- Run tests (if available)
+
+### 4. Review and Commit
+
+Review the changes made and commit when satisfied.
+
+## Learning Your Codebase
+
+This approach is also excellent for exploring unfamiliar code:
+
+```
+Explain how the authentication system works in this codebase
+```
+
+```
+Show me where error handling happens in the API layer
+```
+
+LLMs are excellent at interpreting and analyzing code, whether it was AI-generated or not. Use the agent to:
+
+- Learn about your project
+- Understand how things are built
+- Explore unfamiliar parts of the codebase
+
+## When to Upgrade to Formal Planning
+
+Consider using Quick Flow or full BMad Method when:
+
+- The change affects multiple files or systems
+- You're unsure about the scope
+- The fix keeps growing in complexity
+- You need documentation for the change