# BMAD+ im Team nutzen

> Was versioniert wird und was lokal bleibt, welche Einstellungen man abstimmt, ein Adapter je Teammitglied auf gemeinsamem Rückgrat, sichere Update-Richtlinie, CI-Gates, Onboarding.

Canonical: https://bmad-plus.rochetta.fr/de/docs/guides/for-teams/
Language: de
BMAD+ version: 0.23.1
Documentation reviewed: 2026-10-19
Author: Laurent Rochetta
License: MIT

BMAD+ Dokumentation › [Anleitungen](https://bmad-plus.rochetta.fr/de/docs/guides/) › BMAD+ im Team nutzen

BMAD+ lebt im Projekt, ein Team teilt es also wie jeden anderen Teil des Repositorys: indem es entscheidet, was versioniert wird, was für alle gleich konfiguriert ist und wer es ändert. Diese Seite listet diese Entscheidungen und die Fakten auf, die jede absichern: Besitz-Hashes, erhaltene Änderungen, eine Update-Richtlinie je Projekt, aus einem Rückgrat generierte Adapter. Sie richtet sich an Tech Leads und alle, die Kollegen mit unterschiedlichen KI-Tools einarbeiten müssen. Wo eine Wahl Geschmackssache statt Tatsache ist, sagt der Text es.

<a id="what-to-version"></a>
## Was versioniert wird und was lokal bleibt

**Die von BMAD+ angelegten Dateien und wem sie gehören**

| Dateien | Art | Überlegungen |
| --- | --- | --- |
| `AGENTS.md`, Adapter-Dateien, `.agents/skills/`, `.agents/data/` | Vom Installer generiert und kopiert; im Manifest gehasht. | Sie zu committen gibt jedem Teammitglied dieselben Anweisungen, ohne den Installer auszuführen. Sie nicht zu committen heißt, dass jeder dieselbe Version installiert. Beides funktioniert; wähle eines. |
| `_bmad/config.yaml` | Deine Einstellungen: Sprache, Ausführungsmodus, Checkpoints, uat, swarm. Einmal geschrieben und zusammengeführt, nie überschrieben. | Die naheliegende Datei zum Teilen, denn sie enthält die Konventionen des Teams. |
| `_bmad/update-policy.json` | Von `update-policy` geschrieben, wenn du die Richtlinie änderst. | Teile sie, wenn das Team eine einzige Richtlinie will; sie nennt den erlaubten Versionsbereich. |
| `_bmad/review-rules.yaml` und seine Dokumente | Review-Regeln des Projekts. | Teile sie: Eine Befunddatei beantwortet genau einen Regelsatz, das Team sollte also gegen denselben prüfen. |
| `_bmad/.bmad-plus-install.json` | Das Manifest: Version, Packs, Tools, ein SHA-256 je installierter Datei. | Es muss zu den beschriebenen Dateien passen: versioniere es zusammen mit ihnen oder keins von beiden. |
| `.agents/memory/` | Entscheidungen, Erkenntnisse, Muster, Kontext, Übergaben. | Versioniere es, wenn das Gedächtnis dem Team gehört. Installieren und Aktualisieren überschreiben diese Dateien nie. |
| `.agents/memory/.brain-link` | Der absolute Pfad des auf einer Maschine verknüpften Brains. | Maschinenspezifisch: nicht teilen. |
| `_bmad-output/` | Ergebnisse: Briefings, PRDs, Review-Belege, Abnahmeergebnisse. | Meist teilweise versioniert: Briefings, PRDs, Triage und Ergebnisse sind aufbewahrenswerte Belege. |
| `.bmad/`, `.bmad-plus/` | Update-Cache und -Belege, Memory-Journal, Zustand von Schwärmen und Nexus-Läufen. | Lokaler Zustand. Update-Sperre und Belege betreffen eine einzelne Arbeitskopie. |

<a id="shared-conventions"></a>
## Konventionen, auf die man sich einigen sollte

**Einstellungen und ihre Wirkung auf das Team**

| Einstellung | Wo | Warum abstimmen |
| --- | --- | --- |
| Packs | `install --packs` | Die Packs bestimmen, welche Agenten es gibt. `--packs` und `--tools` ergänzen eine frühere Installation, ein Pack lässt sich also später ohne Verlust hinzufügen. |
| `communication_language`, `document_output_language` | `_bmad/config.yaml` | Die Sprache, in der Agenten sprechen, und die Sprache der Ergebnisse. |
| `execution_mode` | `_bmad/config.yaml` | `manual`, `autopilot` oder `hybrid`: wie viel das Team Nexus allein laufen lässt. |
| `checkpoints` | `_bmad/config.yaml` | Wer was freigibt: `discovery`, `architecture`, `story`, `delivery`, jeweils `require_approval`, `notify_only` oder `auto`. |
| `uat.mode` und `uat.environment` | `_bmad/config.yaml` | `advisory`, `gate` oder `off` sowie die Testumgebung, auf die ein Protokoll zielt. |
| `swarm.budget` und `swarm.wave` | `_bmad/config.yaml` | Wie viele Sub-Agenten ein Lauf nutzen darf, bevor jemand Ja sagen muss (standardmäßig 26 und 10). |
| Review-Regeln | `_bmad/review-rules.yaml` | Derselbe Regelsatz für jeden Reviewer, Mensch oder Agent. |
| Update-Richtlinie | `_bmad/update-policy.json` | Siehe nächster Abschnitt. |

<a id="adapters"></a>
## Ein Rückgrat, ein Adapter je Teammitglied

Alle Adapter werden aus derselben Registry wie `AGENTS.md` generiert, ein Kollege mit Cursor und einer mit Claude Code bekommen also dieselbe Liste und dieselben Regeln; nur das Dateiformat unterscheidet sich. `--tools` nimmt mehrere IDs zugleich (`--tools claude-code,cursor`), `all` oder `none`. Der Installer erkennt Tools an ihren Ordnern (`.claude/`, `.gemini/`, `.cursor/`, `.codex/`, `.opencode/`, `.aider.conf.yml`), wenn du kein `--tools` angibst; `--yes` ohne erkanntes Tool schreibt keinen Adapter. Ein BMAD+-Adapter, den du bearbeitet hast, bleibt erhalten. Eine Anweisungsdatei, die du selbst geschrieben hast, bleibt bei einer interaktiven Installation und bei `update` erhalten; `install --yes` sichert sie zuerst als `<file>.bak` und ersetzt sie dann. Alte Installer-Dateien werden als `<file>.bak` gesichert.

**Adapter**

| Tool-ID | Geschriebene Datei | Erkannt an |
| --- | --- | --- |
| `claude-code` | `CLAUDE.md` | ein Ordner `.claude/` |
| `gemini-cli` | `GEMINI.md` | ein Ordner `.gemini/` |
| `antigravity` | `GEMINI.md` (mit gemini-cli geteilt) | ein Ordner `.gemini/antigravity/` |
| `cursor` | `.cursor/rules/bmad-plus.mdc` (immer angewendet) | ein Ordner `.cursor/` |
| `codex-cli` | `.codex/AGENTS.md` | ein Ordner `.codex/` |
| `opencode` | `.opencode/AGENTS.md` | ein Ordner `.opencode/` |
| `aider` | `CONVENTIONS.md`; füge `read: CONVENTIONS.md` zu `.aider.conf.yml` hinzu oder führe `/read CONVENTIONS.md` in Aider aus | eine Datei `.aider.conf.yml` |

Wer später ein Tool ergänzt, führt den Installer erneut mit diesem Tool aus: Der Lauf behält das bereits Installierte und fügt den fehlenden Adapter hinzu. `--tools none` installiert Agenten, Skills und Gedächtnis, ohne die Konfiguration irgendeines Tools anzufassen; das ist die richtige Option für ein Projekt, dessen `CLAUDE.md` oder `AGENTS.md` von Hand gepflegt wird.

<a id="update-policy"></a>
## Eine sichere Update-Richtlinie

Der Standard ist Benachrichtigung: Die generierten Anweisungen bitten den Assistenten, einmal pro Sitzung `update-check` auszuführen und zu berichten. Nichts wird angewendet. Für ein Team ist das praktische Muster eine Person (oder ein CI-Job), die entscheidet, wann gewechselt wird, `update` anwendet, den Bericht prüft und committet; die anderen bekommen das Ergebnis mit ihrem nächsten Pull. Soll das Team Updates ohne Mensch durchlaufen lassen, braucht `auto` einen ausdrücklichen Semver-Bereich und mehrere Schutzbedingungen: Das Registry-Ergebnis muss frisch sein, die verwalteten Dateien unverändert, das Hash-Inventar der Installation vollständig, die Zielversion genau die im Befehl festgehaltene und die Node-Anforderung erfüllt. Eine Offline-, veraltete oder fehlgeschlagene Abfrage erlaubt nie ein automatisches Update.

**Die Richtlinie lesen und setzen**

```text
$ npx bmad-plus update-policy
Update policy: notify; channel=latest; range=none; prereleases=false
$ npx bmad-plus update-policy --json
{"policy":{"mode":"notify","channel":"latest","allowedRange":null,"allowPrerelease":false,"registry":"https://registry.npmjs.org/"},"changed":false}
$ npx bmad-plus update-policy --mode auto --range "^0.23.0"
Update policy saved: auto; channel=latest; range=^0.23.0; prereleases=false
$ npx bmad-plus update-policy --mode notify
Update policy saved: notify; channel=latest; range=^0.23.0; prereleases=false
$ npx bmad-plus update-check --offline --json
{"schemaVersion":1,"installedVersion":"0.23.0","runningVersion":"0.23.0","latestVersion":null,"targetVersion":null,"channel":"latest","status":"unknown","checkedAt":null,"source":"none","stale":false,"updateAvailable":null,"releaseEligible":false,"versionEligible":false,"canAutoApply":false,"engineCompatible":null,"engines":{},"reason":"offline"}
```

Ausgabe eines echten Laufs. Quelle: Auf einem Testserver am 2026-10-18 mit dem Quellcode 0.23.0 (tools/cli/bmad-plus-cli.js) in einem Wegwerf-Git-Projekt nachgespielt

- `off` stoppt jede Abfrage. `notify` (Standard) berichtet. `auto` braucht `--range`; ergänze `--allow-prerelease` oder `--stable-only`, um Vorabversionen zu steuern. Die Registry ist fest auf `https://registry.npmjs.org/` gesetzt.
- Ein Update erhält seit dem erfassten Hash geänderte Dateien und meldet sie; ein Konflikt blockiert den automatischen Weg. Dateien, die eine neue Version nicht mehr liefert, werden nach einer wiederherstellbaren Sicherung entfernt. Jedes angewendete Update schreibt `.bmad/updates/<receipt-id>/` mit `receipt.json` und `backups/`; `update --restore <receipt-id> --yes` kehrt dorthin zurück und überschreibt spätere lokale Änderungen nicht.
- Eine Installation vor 0.13 (ohne Datei-Hashes) lässt sich nicht automatisch aktualisieren; eine ausdrückliche Migration, `npx --yes bmad-plus@0.23.1 update --yes`, sichert, was sie ersetzt.
- `install` ändert nie die installierte Version: Ein Downgrade wird abgelehnt, und ein Upgrade läuft über `update`. Haben zwei Teammitglieder verschiedene Versionen installiert, führt das mit der älteren `update` aus.
- Eine Sperre `.bmad/update.lock` schützt das Projekt während eines Updates (nach 60 Minuten oder bei totem Besitzer als veraltet betrachtet); `doctor` meldet eine Sperre, die nicht seine eigene ist.

<a id="ci-and-gates"></a>
## CI und Gates

BMAD+ installiert keinen Git-Hook und keinen Lifecycle-Hook in deinem Projekt, weil eine Anweisung übersprungen werden kann. Was ein Team durchsetzen will, setzt es mit seiner eigenen CI durch, über Exit-Codes, die dafür gedacht sind.

**Prüfungen, die ein Team in die CI einhängen kann**

| Prüfung | Befehl | Scheitert wenn |
| --- | --- | --- |
| Integrität der Installation | `bmad-plus doctor --json` | Exit 1 bei jedem Fehler (etwa einer fehlenden Pflichtdatei). Geänderte Dateien sind Warnungen. |
| Update-Bewusstsein | `bmad-plus update-check --json` | Exit 1 bei ungültiger Laufzeit, Installation oder Richtlinie; eine unerreichbare Registry ergibt `unknown`, keinen Fehler. |
| Review-Gate bei Pull Requests | Die Rezepte in `docs/recipes/ci-review/` | Das Review ist unvollständig (Exit 2) oder hat offene Befunde (Exit 1). |
| Eine Version hat einen akzeptierten menschlichen Lauf | `uat-release-gate.mjs` aus dem Skill uat | Kein abgeschlossener Lauf, andere Revision, nicht klassifizierter Fehler, unbestätigter Schreibvorgang (Exits 1 bis 3; 4 heißt, das Gate konnte nicht laufen). |
| Eine Version hat überhaupt ein Protokoll | `uat-spec-present.mjs` | Kein Protokoll nennt die Version aus `package.json`. |
| Eine Team-Intake-Datei ist gültig | `bmad-plus intake check FILE` | Exit 1 mit allen aufgelisteten Problemen. |
| Shield-Belege | `bmad-plus assurance verify` und `ai-register check` | `assurance verify` endet mit 1, wenn eine Behauptung nicht belegt ist; `ai-register check` warnt nur. |

<a id="onboarding"></a>
## Eine Kollegin oder einen Kollegen einarbeiten

1. **Repository ziehen und Installation prüfen** Sind die generierten Dateien committet, funktioniert `doctor` bereits. Falls nicht, führe den Installer mit der Pack-Liste des Teams aus, dann `doctor`.

   ```sh
   npx bmad-plus@0.23.1 install --packs core,memory --tools claude-code
   npx bmad-plus@0.23.1 doctor
   ```
2. **Das eigene Tool ergänzen** Installiere mit der ID deines Tools; die vorhandenen Dateien bleiben erhalten und dein Adapter kommt hinzu.

   ```sh
   npx bmad-plus@0.23.1 install --packs core,memory --tools cursor
   ```
3. **Das Rückgrat lesen, dann den Assistenten fragen** Öffne `AGENTS.md` für die Agent-Liste und die Regeln des Teams und tippe `bmad-help` im Chat. Lies die Einstellungen in `_bmad/config.yaml`, damit du weißt, welche Checkpoints anhalten und dich fragen.
4. **Das Gedächtnis mit deiner Maschine verknüpfen** Mit dem Memory-Pack erkennt die Installation ein Brain auf deiner Maschine (`BMAD_PLUS_BRAIN`, ein Ordner `_brain/` in einem übergeordneten Verzeichnis, `~/.bmad-plus/brain/`, dann ein nicht leeres `~/.claude/memory/`) und hält es in `.agents/memory/.brain-link` fest. Diese Datei gehört nur dir; die Projektgedächtnisdateien darum herum gehören dem Team.

<a id="governance"></a>
## Governance-Hinweise für Teams

- Freigaben: Soll im Team eine Person Architektur und Auslieferung freigeben, lass `require_approval` an diesen Checkpoints. Ein Autopilot mit `auto` überall ist eine bewusste Entscheidung, kein Standard.
- Budget: Ein Schwarm über `swarm.budget` wird abgelehnt, bis ein Mensch Ja sagt; kostenpflichtige Medienerzeugung wird jedes Mal erfragt. Niemand sollte `--approved` im Namen eines anderen übergeben.
- OSINT: Die Recherche zu einer namentlich genannten Person verlangt bei jedem Lauf einen erfassten Zweck und eine Rechtsgrundlage. Im Team heißt das: jemand, der diese Entscheidung trägt. Siehe die Vertrauensseite.
- Shield: Die Berichte sind KI-generiert und tragen den Vermerk „not legal advice“; eine Compliance-Entscheidung bleibt bei einer qualifizierten Person.
- Geheimnisse: API-Schlüssel gehören in die Umgebung jeder Person oder der CI, nie ins Repository. Die Schwärzungs-Untergrenze von Review und Abnahmenotizen maskiert gängige Zugangsdaten-Formen; sie ersetzt nicht, keine Geheimnisse zu committen.
- Besitz: Jede von BMAD+ geschriebene Datei ist gehasht. Eine von einem Teammitglied bearbeitete Datei bleibt bei Update und Deinstallation erhalten und wird von `doctor` als geändert gemeldet (eine Warnung): Lokale Anpassung ist sichtbar und wird nicht still überschrieben.

<a id="example-team-conventions-review"></a>
### Die BMAD+-Konventionen des Teams prüfen

Nutze es, wenn ein neuer Tech Lead übernimmt oder bevor du einen Kollegen einarbeitest. Der Assistent liest nur; nichts wird geändert.

**In deinem KI-Assistenten**

```text
Lies _bmad/config.yaml, _bmad/update-policy.json falls vorhanden, _bmad/review-rules.yaml falls vorhanden und das Manifest _bmad/.bmad-plus-install.json. Fasse in einer Tabelle zusammen: installierte Version, Packs, Tools, Ausführungsmodus, Verhalten jedes Kontrollpunkts, uat-Modus, Schwarm-Budget, Modus und Bereich der Update-Richtlinie. Liste dann auf, was ein neues Teammitglied tun müsste, um dasselbe Setup zu erhalten, und kennzeichne jede Einstellung, die mit den anderen unstimmig wirkt. Ändere nichts.
```

**Das solltest du erhalten** Eine Tabelle der aus den Dateien gelesenen echten Werte, eine Onboarding-Liste (mit denselben Packs installieren, das eigene Tool ergänzen, das Rückgrat lesen) und eine kurze Liste von Unstimmigkeiten, zum Beispiel `execution_mode: autopilot` mit allen Checkpoints auf `auto`. Keine Datei wird geändert.

**Siehe auch**

- [Deine erste Stunde mit BMAD+](https://bmad-plus.rochetta.fr/de/docs/guides/first-hour/)
- [Installieren, aktualisieren, deinstallieren](https://bmad-plus.rochetta.fr/de/docs/guides/install-lifecycle/)
- [Referenz: config.yaml](https://bmad-plus.rochetta.fr/de/docs/reference/config-yaml/)
- [Referenz: Adapter](https://bmad-plus.rochetta.fr/de/docs/reference/adapters/)
- [Vertrauen und Eigentum](https://bmad-plus.rochetta.fr/de/docs/security/trust-and-ownership/)
- [Datenverarbeitung](https://bmad-plus.rochetta.fr/de/docs/security/data-handling/)

[BMAD+ Dokumentation](https://bmad-plus.rochetta.fr/de/docs/) · [Anleitungen](https://bmad-plus.rochetta.fr/de/docs/guides/)

[Quellcode auf GitHub](https://github.com/lrochetta/BMAD-PLUS)