1.9 KiB
1.9 KiB
Making a team's BMad follow shared rules
Open this when a lead wants every teammate's BMad to use the same rules, tools, templates, publishing targets, or paths. bmad-customize writes each change; this file is for choosing where a rule goes. How overrides merge is in help/customization.md.
Pick the place by scope
| The rule applies to | Put it in |
|---|---|
| Every workflow one agent runs | That agent skill's team override |
| One workflow | That workflow skill's team override |
| Several workflows | One override per workflow |
| A shared path or a setup answer | Central config, _bmad/custom/config.toml, edited by hand |
| Every session, even with no skill active | The repository's AGENTS.md, kept short |
Team override files live under _bmad/custom/ and are committed, so teammates get a change on their next pull. Personal .user.toml files stay out of git and win over the team file. Remind the user to commit after bmad-customize writes a team file.
What a team can set
- Standing facts. Sentences every run must respect ("Our org is AWS-only"), or a pointer to a standards document the team already maintains, which is better than copying it.
- Required tools. Name the exact tool and when to call it. Teammates need that tool connected.
- Publishing on completion. Instructions that run once after a skill writes its output, such as posting the document to a wiki or opening a ticket. They should ask before any action teammates will see.
- Writing standards and knowledge sources, on the skills that expose them.
- Templates. Point a skill at the team's own template, kept in the repository. Start from a copy of the shipped one and keep its headings.
- Output locations and shared paths, pinned in central config. Pin only what the whole team must share.
Not every skill exposes every one of these. bmad-customize lists what a given skill allows and never invents a field.