bmad-method 5.1.3 → 6.0.0-Beta.1

package/CNAME

@@ -0,0 +1 @@
+docs.bmad-method.org

package/CONTRIBUTING.md

@@ -1,209 +1,167 @@
-# Contributing to this project
+# Contributing to BMad
 
-Thank you for considering contributing to this project! This document outlines the process for contributing and some guidelines to follow.
+Thank you for considering contributing! We believe in **Human Amplification, Not Replacement** — bringing out the best thinking in both humans and AI through guided collaboration.
 
-🆕 **New to GitHub or pull requests?** Check out our [beginner-friendly Pull Request Guide](docs/how-to-contribute-with-pull-requests.md) first!
+💬 **Discord**: [Join our community](https://discord.gg/gk8jAdXWmj) for real-time discussions, questions, and collaboration.
 
-📋 **Before contributing**, please read our [Guiding Principles](docs/GUIDING-PRINCIPLES.md) to understand the BMad Method's core philosophy and architectural decisions.
+---
 
-Also note, we use the discussions feature in GitHub to have a community to discuss potential ideas, uses, additions and enhancements.
+## Our Philosophy
 
-💬 **Discord Community**: Join our [Discord server](https://discord.gg/gk8jAdXWmj) for real-time discussions:
+BMad strengthens human-AI collaboration through specialized agents and guided workflows. Every contribution should answer: **"Does this make humans and AI better together?"**
 
-- **#general-dev** - Technical discussions, feature ideas, and development questions
-- **#bugs-issues** - Bug reports and issue discussions
+**✅ What we welcome:**
+- Enhanced collaboration patterns and workflows
+- Improved agent personas and prompts
+- Domain-specific modules leveraging BMad Core
+- Better planning and context continuity
 
-## Code of Conduct
-
-By participating in this project, you agree to abide by our Code of Conduct. Please read it before participating.
-
-## How to Contribute
-
-### Reporting Bugs
-
-1. **Check existing issues** first to avoid duplicates
-2. **Use the bug report template** when creating a new issue - it will guide you through providing:
-   - Clear bug description
-   - Steps to reproduce
-   - Expected vs actual behavior
-   - Model/IDE/BMad version details
-   - Screenshots or links if applicable
-3. **Consider discussing in Discord** (#bugs-issues channel) for quick help
-4. **Indicate if you're working on a fix** to avoid duplicate efforts
-
-### Suggesting Features
-
-1. **Discuss first in Discord** (#general-dev channel) - the feature request template asks if you've done this
-2. **Check existing issues and discussions** to avoid duplicates
-3. **Use the feature request template** when creating an issue - it will guide you through:
-   - Confirming Discord discussion
-   - Describing the problem it solves
-   - Explaining your solution
-   - Listing alternatives considered
-4. **Be specific** about why this feature would benefit the BMad community
+**❌ What doesn't fit:**
+- Purely automated solutions that sideline humans
+- Complexity that creates barriers to adoption
+- Features that fragment BMad Core's foundation
 
-### Pull Request Process
+---
 
-⚠️ **Before starting work:**
+## Reporting Issues
 
-1. **For bugs**: Check if an issue exists (create one using the bug template if not)
-2. **For features**: Ensure you've discussed in Discord (#general-dev) AND created a feature request issue
-3. **For large changes**: Always open an issue first to discuss alignment
+**ALL bug reports and feature requests MUST go through GitHub Issues.**
 
-Please only propose small granular commits! If its large or significant, please discuss in the discussions tab and open up an issue first. I do not want you to waste your time on a potentially very large PR to have it rejected because it is not aligned or deviates from other planned changes. Communicate and lets work together to build and improve this great community project!
+### Before Creating an Issue
 
-**Important**: All contributions must align with our [Guiding Principles](docs/GUIDING-PRINCIPLES.md). Key points:
+1. **Search existing issues** — Use the GitHub issue search to check if your bug or feature has already been reported
+2. **Search closed issues** — Your issue may have been fixed or addressed previously
+3. **Check discussions** — Some conversations happen in [GitHub Discussions](https://github.com/bmad-code-org/BMAD-METHOD/discussions)
 
-- Keep dev agents lean - they need context for coding, not documentation
-- Web/planning agents can be larger with more complex tasks
-- Everything is natural language (markdown) - no code in core framework
-- Use expansion packs for domain-specific features
+### Bug Reports
 
-#### Which Branch for Your PR?
+After searching, if the bug is unreported, use the [bug report template](https://github.com/bmad-code-org/BMAD-METHOD/issues/new?template=bug_report.md) and include:
 
-**Submit to `next` branch** (most contributions):
+- Clear description of the problem
+- Steps to reproduce
+- Expected vs actual behavior
+- Your environment (model, IDE, BMad version)
+- Screenshots or error messages if applicable
 
-- ✨ New features or agents
-- 🎨 Enhancements to existing features
-- 📚 Documentation updates
-- ♻️ Code refactoring
-- ⚡ Performance improvements
-- 🧪 New tests
-- 🎁 New expansion packs
+### Feature Requests
 
-**Submit to `main` branch** (critical only):
+After searching, use the [feature request template](https://github.com/bmad-code-org/BMAD-METHOD/issues/new?template=feature_request.md) and explain:
 
-- 🚨 Critical bug fixes that break basic functionality
-- 🔒 Security patches
-- 📚 Fixing dangerously incorrect documentation
-- 🐛 Bugs preventing installation or basic usage
+- What the feature is
+- Why it would benefit the BMad community
+- How it strengthens human-AI collaboration
 
-**When in doubt, submit to `next`**. We'd rather test changes thoroughly before they hit stable.
+**For community modules**, review [TRADEMARK.md](TRADEMARK.md) for proper naming conventions (e.g., "My Module (BMad Community Module)").
 
-#### PR Size Guidelines
+---
 
-- **Ideal PR size**: 200-400 lines of code changes
-- **Maximum PR size**: 800 lines (excluding generated files)
-- **One feature/fix per PR**: Each PR should address a single issue or add one feature
-- **If your change is larger**: Break it into multiple smaller PRs that can be reviewed independently
-- **Related changes**: Even related changes should be separate PRs if they deliver independent value
+## Before Starting Work
 
-#### Breaking Down Large PRs
+⚠️ **Required before submitting PRs:**
 
-If your change exceeds 800 lines, use this checklist to split it:
+| Work Type     | Requirement                                    |
+| ------------- | ---------------------------------------------- |
+| Bug fix       | An open issue (create one if it doesn't exist) |
+| Feature       | An open feature request issue                  |
+| Large changes | Discussion via issue first                     |
 
-- [ ] Can I separate the refactoring from the feature implementation?
-- [ ] Can I introduce the new API/interface in one PR and implementation in another?
-- [ ] Can I split by file or module?
-- [ ] Can I create a base PR with shared utilities first?
-- [ ] Can I separate test additions from implementation?
-- [ ] Even if changes are related, can they deliver value independently?
-- [ ] Can these changes be merged in any order without breaking things?
+**Why?** This prevents wasted effort on work that may not align with project direction.
 
-Example breakdown:
+---
 
-1. PR #1: Add utility functions and types (100 lines)
-2. PR #2: Refactor existing code to use utilities (200 lines)
-3. PR #3: Implement new feature using refactored code (300 lines)
-4. PR #4: Add comprehensive tests (200 lines)
+## Pull Request Guidelines
 
-**Note**: PRs #1 and #4 could be submitted simultaneously since they deliver independent value and don't depend on each other's merge order.
+### Target Branch
 
-#### Pull Request Steps
+Submit PRs to the `main` branch.
 
-1. Fork the repository
-2. Create a new branch (`git checkout -b feature/your-feature-name`)
-3. Make your changes
-4. Run any tests or linting to ensure quality
-5. Commit your changes with clear, descriptive messages following our commit message convention
-6. Push to your branch (`git push origin feature/your-feature-name`)
-7. Open a Pull Request against the main branch
+### PR Size
 
-## Issue Templates
+- **Ideal**: 200-400 lines of code changes
+- **Maximum**: 800 lines (excluding generated files)
+- **One feature/fix per PR**
 
-We use GitHub issue templates to ensure all necessary information is provided:
+If your change exceeds 800 lines, break it into smaller PRs that can be reviewed independently.
 
-- **Bug Reports**: Automatically guides you through providing reproduction steps, environment details, and expected behavior
-- **Feature Requests**: Requires Discord discussion confirmation and asks for problem/solution descriptions
+### New to Pull Requests?
 
-Using these templates helps maintainers understand and address your contribution faster.
-
-## Pull Request Description Guidelines
-
-Keep PR descriptions short and to the point following this template:
+1. **Fork** the repository
+2. **Clone** your fork: `git clone https://github.com/YOUR-USERNAME/bmad-method.git`
+3. **Create a branch**: `git checkout -b fix/description` or `git checkout -b feature/description`
+4. **Make changes** — keep them focused
+5. **Commit**: `git commit -m "fix: correct typo in README"`
+6. **Push**: `git push origin fix/description`
+7. **Open PR** from your fork on GitHub
 
 ### PR Description Template
 
-Keep your PR description concise and focused. Use this template:
-
 ```markdown
 ## What
-
 [1-2 sentences describing WHAT changed]
 
 ## Why
-
 [1-2 sentences explaining WHY this change is needed]
-Fixes #[issue number] (if applicable)
+Fixes #[issue number]
 
 ## How
-
-[2-3 bullets listing HOW you implemented it]
-
--
--
+- [2-3 bullets listing HOW you implemented it]
 -
 
 ## Testing
-
 [1-2 sentences on how you tested this]
 ```
 
-**Maximum PR description length: 200 words** (excluding code examples if needed)
+**Keep it under 200 words.**
 
-### Good vs Bad PR Descriptions
+### Commit Messages
 
-❌ **Bad Example:**
+Use conventional commits:
 
-> This revolutionary PR introduces a paradigm-shifting enhancement to the system's architecture by implementing a state-of-the-art solution that leverages cutting-edge methodologies to optimize performance metrics and deliver unprecedented value to stakeholders through innovative approaches...
+- `feat:` New feature
+- `fix:` Bug fix
+- `docs:` Documentation only
+- `refactor:` Code change (no bug/feature)
+- `test:` Adding tests
+- `chore:` Build/tools changes
 
-✅ **Good Example:**
+Keep messages under 72 characters. Each commit = one logical change.
 
-> **What:** Added validation for agent dependency resolution
-> **Why:** Build was failing silently when agents had circular dependencies
-> **How:**
->
-> - Added cycle detection in dependency-resolver.js
-> - Throws clear error with dependency chain
->   **Testing:** Tested with circular deps between 3 agents
+---
 
-## Commit Message Convention
+## What Makes a Good PR?
 
-Use conventional commits format:
+| ✅ Do                        | ❌ Don't                      |
+| --------------------------- | ---------------------------- |
+| Change one thing per PR     | Mix unrelated changes        |
+| Clear title and description | Vague or missing explanation |
+| Reference related issues    | Reformat entire files        |
+| Small, focused commits      | Copy your whole project      |
+| Work on a branch            | Work directly on `main`      |
 
-- `feat:` New feature
-- `fix:` Bug fix
-- `docs:` Documentation only
-- `refactor:` Code change that neither fixes a bug nor adds a feature
-- `test:` Adding missing tests
-- `chore:` Changes to build process or auxiliary tools
+---
 
-Keep commit messages under 72 characters.
+## Prompt & Agent Guidelines
 
-### Atomic Commits
+- Keep dev agents lean — focus on coding context, not documentation
+- Web/planning agents can be larger with complex tasks
+- Everything is natural language (markdown) — no code in core framework
+- Use BMad modules for domain-specific features
+- Validate YAML schemas: `npm run validate:schemas`
 
-Each commit should represent one logical change:
+---
 
-- **Do:** One bug fix per commit
-- **Do:** One feature addition per commit
-- **Don't:** Mix refactoring with bug fixes
-- **Don't:** Combine unrelated changes
+## Need Help?
 
-## Code Style
+- 💬 **Discord**: [Join the community](https://discord.gg/gk8jAdXWmj)
+- 🐛 **Bugs**: Use the [bug report template](https://github.com/bmad-code-org/BMAD-METHOD/issues/new?template=bug_report.md)
+- 💡 **Features**: Use the [feature request template](https://github.com/bmad-code-org/BMAD-METHOD/issues/new?template=feature_request.md)
+
+---
+
+## Code of Conduct
 
-- Follow the existing code style and conventions
-- Write clear comments for complex logic
+By participating, you agree to abide by our [Code of Conduct](.github/CODE_OF_CONDUCT.md).
 
 ## License
 
-By contributing to this project, you agree that your contributions will be licensed under the same license as the project.
+By contributing, your contributions are licensed under the same MIT License. See [CONTRIBUTORS.md](CONTRIBUTORS.md) for contributor attribution.

package/CONTRIBUTORS.md

@@ -0,0 +1,32 @@
+# Contributors
+
+BMad Core, BMad Method and BMad and Community BMad Modules are made possible by contributions from our community. We gratefully acknowledge everyone who has helped improve this project.
+
+## How We Credit Contributors
+
+- **Git history** — Every contribution is preserved in the project's commit history
+- **Contributors badge** — See the dynamic contributors list on our [README](README.md)
+- **GitHub contributors graph** — Visual representation at <https://github.com/bmad-code-org/BMAD-METHOD/graphs/contributors>
+
+## Becoming a Contributor
+
+Anyone who submits a pull request that is merged becomes a contributor. Contributions include:
+
+- Bug fixes
+- New features or workflows
+- Documentation improvements
+- Bug reports and issue triaging
+- Code reviews
+- Helping others in discussions
+
+There are no minimum contribution requirements — whether it's a one-character typo fix or a major feature, we value all contributions.
+
+## Copyright
+
+The BMad Method project is copyrighted by BMad Code, LLC. Individual contributions are licensed under the same MIT License as the project. Contributors retain authorship credit through Git history and the contributors graph.
+
+---
+
+**Thank you to everyone who has helped make BMad Method better!**
+
+For contribution guidelines, see [CONTRIBUTING.md](CONTRIBUTING.md).

package/LICENSE

@@ -1,6 +1,9 @@
 MIT License
 
-Copyright (c) 2025 Brian AKA BMad AKA BMad Code
+Copyright (c) 2025 BMad Code, LLC
+
+This project incorporates contributions from the open source community.
+See [CONTRIBUTORS.md](CONTRIBUTORS.md) for contributor attribution.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
@@ -19,3 +22,9 @@ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
+
+TRADEMARK NOTICE:
+BMad™, BMad Method™, and BMad Core™ are trademarks of BMad Code, LLC, covering all
+casings and variations (including BMAD, bmad, BMadMethod, BMAD-METHOD, etc.). The use of
+these trademarks in this software does not grant any rights to use the trademarks
+for any other purpose. See [TRADEMARK.md](TRADEMARK.md) for detailed guidelines.