Compare commits

...

5 Commits

Author SHA1 Message Date
Alex Verkhovsky a842381435
Merge 63a03b6945 into c8ca083316 2026-02-12 12:29:10 -07:00
Alex Verkhovsky 63a03b6945
Merge branch 'main' into docs/branching-strategy 2026-02-12 12:29:07 -07:00
Pablo LION c8ca083316
fix: remove unnecessary quotes and fix grammar in bmad-master principles (#1600)
- Remove YAML quotes from principles list item (consistency with other agents)
- Add missing comma: "at runtime never" → "at runtime, never" (run-on fix)

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-12 12:10:33 -06:00
Pablo LION 5b79330f72
fix: fix typos in tech-writer and ux-designer agent definitions (#1599)
- tech-writer: "1000s works" → "1000s of words" (idiom typo)
- ux-designer: "PRovides" → "Provides", "that" → "than" (typos in description)

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-02-12 12:09:12 -06:00
Alex Verkhovsky ec72336c2e docs: add branching strategy (stable-branch model) 2026-02-08 12:28:45 -07:00
5 changed files with 62 additions and 4 deletions

58
BRANCHING.md Normal file
View File

@ -0,0 +1,58 @@
# Branching Strategy
BMad uses a **stable-branch** model: `main` is the development branch, and numbered branches hold stable releases that receive only cherry-picked fixes.
```
main ●───●───●───●───●───●───●───●──────► 7.0, ...
\ \
v6 ●───●───● \ patches only
│ │ │ \
v6.0.0 v6.0.2 \
│ \
v6.0.1 \
\
v6.1 ●───●───● patches only
│ │
v6.1.0 v6.1.1
```
Every minor version (6.0, 6.1, ...) ships from `main` as its own stable branch. Only patches are cherry-picked onto stable branches.
This pattern is used by Node.js, Go, and Python — adapted here for a project that ships an npm CLI.
---
## The Three Lanes
| Branch | Purpose | What goes here | Gets tagged? |
| --- | --- | --- | --- |
| `main` | Next version development | All new work, via PRs | Pre-release only (`X.Y.0-alpha.N`) |
| `v<major.minor>` (e.g., `v6`, `v6.1`) | Stable release maintenance | Cherry-picks from `main` only | Yes — `vX.Y.Z` |
| Forks | Experimental work | Anything | Never |
### Rules
1. **All fixes must land on `main` first**, then get cherry-picked to the stable branch.
2. **One stable branch at a time.** When a new major version ships, the old one stops receiving patches.
---
## Lifecycle
**New version:** Feature branches target `main` (see [CONTRIBUTING.md](CONTRIBUTING.md)). Pre-release tags cut from `main` as needed.
**Stable release:** When ready, cut a stable branch from `main` (e.g., `v6`, `v6.1`), tag it, bump `main` to the next version. From that point, `main` is the next release.
**Patch:** Fix lands on `main` via normal PR. Cherry-pick the merged commit to the stable branch. Tag the patch release.
**Retirement:** When the next major ships, the old stable branch is left as-is. Tags remain as permanent references.
---
## FAQ
**Why not Git Flow?**
Git Flow adds a `develop` branch and release branches per version. For one active version and a small team, that's overhead without benefit.
**Why cherry-pick instead of merging `main` into stable?**
Cherry-picking isolates fixes; merging would pull incomplete features from `main`.

View File

@ -73,7 +73,7 @@ After searching, use the [feature request template](https://github.com/bmad-code
### Target Branch ### Target Branch
Submit PRs to the `main` branch. Submit PRs to the `main` branch unless you are patching a stable release branch. See [BRANCHING.md](BRANCHING.md) for details on the stable-branch model.
### PR Size ### PR Size

View File

@ -16,7 +16,7 @@ agent:
communication_style: "Patient educator who explains like teaching a friend. Uses analogies that make complex simple, celebrates clarity when it shines." communication_style: "Patient educator who explains like teaching a friend. Uses analogies that make complex simple, celebrates clarity when it shines."
principles: | principles: |
- Every Technical Document I touch helps someone accomplish a task. Thus I strive for Clarity above all, and every word and phrase serves a purpose without being overly wordy. - Every Technical Document I touch helps someone accomplish a task. Thus I strive for Clarity above all, and every word and phrase serves a purpose without being overly wordy.
- I believe a picture/diagram is worth 1000s works and will include diagrams over drawn out text. - I believe a picture/diagram is worth 1000s of words and will include diagrams over drawn out text.
- I understand the intended audience or will clarify with the user so I know when to simplify vs when to be detailed. - I understand the intended audience or will clarify with the user so I know when to simplify vs when to be detailed.
- I will always strive to follow `_bmad/_memory/tech-writer-sidecar/documentation-standards.md` best practices. - I will always strive to follow `_bmad/_memory/tech-writer-sidecar/documentation-standards.md` best practices.

View File

@ -24,4 +24,4 @@ agent:
menu: menu:
- trigger: CU or fuzzy match on ux-design - trigger: CU or fuzzy match on ux-design
exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md" exec: "{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/workflow.md"
description: "[CU] Create UX: Guidance through realizing the plan for your UX to inform architecture and implementation. PRovides more details that what was discovered in the PRD" description: "[CU] Create UX: Guidance through realizing the plan for your UX to inform architecture and implementation. Provides more details than what was discovered in the PRD"

View File

@ -15,7 +15,7 @@ agent:
identity: "Master-level expert in the BMAD Core Platform and all loaded modules with comprehensive knowledge of all resources, tasks, and workflows. Experienced in direct task execution and runtime resource management, serving as the primary execution engine for BMAD operations." identity: "Master-level expert in the BMAD Core Platform and all loaded modules with comprehensive knowledge of all resources, tasks, and workflows. Experienced in direct task execution and runtime resource management, serving as the primary execution engine for BMAD operations."
communication_style: "Direct and comprehensive, refers to himself in the 3rd person. Expert-level communication focused on efficient task execution, presenting information systematically using numbered lists with immediate command response capability." communication_style: "Direct and comprehensive, refers to himself in the 3rd person. Expert-level communication focused on efficient task execution, presenting information systematically using numbered lists with immediate command response capability."
principles: | principles: |
- "Load resources at runtime never pre-load, and always present numbered lists for choices." - Load resources at runtime, never pre-load, and always present numbered lists for choices.
critical_actions: critical_actions:
- "Always greet the user and let them know they can use `/bmad-help` at any time to get advice on what to do next, and they can combine that with what they need help with <example>`/bmad-help where should I start with an idea I have that does XYZ`</example>" - "Always greet the user and let them know they can use `/bmad-help` at any time to get advice on what to do next, and they can combine that with what they need help with <example>`/bmad-help where should I start with an idea I have that does XYZ`</example>"