# Projektstruktur
> Jeder Ordner und jede Datei, die BMAD+ in einem Projekt und auf deinem Rechner anlegt, welcher Befehl sie erzeugt und ob sie dir gehört, BMAD+ sie verwaltet oder als Zustand unberührt bleiben soll.
Canonical: https://bmad-plus.rochetta.fr/de/docs/reference/project-layout/
Language: de
BMAD+ version: 0.23.1
Documentation reviewed: 2026-10-19
Author: Laurent Rochetta
License: MIT
BMAD+ Dokumentation › [Referenz](https://bmad-plus.rochetta.fr/de/docs/reference/) › Projektstruktur
BMAD+ schreibt an ein paar gut benannte Stellen und sonst nirgends. Wer weiß, was was ist, beantwortet die drei praktischen Fragen: Was darf ich bearbeiten, was sollte ich einchecken und was wird bei einer Deinstallation entfernt. Diese Seite kartiert alle.
## Die Karte
**Ein Projekt mit mehreren Packs nach etwas Nutzung (Ordner entstehen, wenn die Befehle laufen, die sie anlegen)**
```text
your-project/
├── AGENTS.md common spine for every assistant
├── CLAUDE.md, GEMINI.md, ... one adapter per selected tool
├── .agents/
│ ├── skills/ agents, packs and skills (agent-*, pack-*, bmad-plus-*, ...)
│ ├── data/role-triggers.yaml auto-activation rules
│ └── memory/ project memory (Memory pack)
├── _bmad/
│ ├── config.yaml your settings
│ ├── module.yaml, module-help.csv
│ ├── .bmad-plus-install.json install manifest (ownership hashes)
│ └── update-policy.json only after update-policy
├── _bmad-output/ deliverables written by agents and commands
│ ├── discovery/ build/ created by install
│ └── uat/ review/ assurance/ design/ dev-studio/ osint-reports/ ready-to-integrate/
├── .bmad/ local state: caches, locks, receipts, journals, Python environments
├── .bmad-plus/ durable run state: swarm/ and nexus/
├── docs/ created empty by install
└── backups/ only with the Backup pack
```
## Was wem gehört
Eigentum wird festgehalten, nicht geraten. Bei der Installation speichert BMAD+ einen Inhalts-Hash jeder Datei, die es unter `.agents/` kopiert, sowie von `_bmad/module.yaml` und `_bmad/module-help.csv`: Diese Liste ist das Datei-Inventar im Manifest. Eine Datei, deren Hash noch passt, gehört BMAD+: `update` frischt sie auf, `uninstall` entfernt sie. Eine Datei, die du geändert hast oder die BMAD+ nie geliefert hat, gehört dir: `update` behält sie und meldet einen Konflikt, `uninstall` lässt sie stehen. Deine Einstellungen, dein Gedächtnis und die Ergebnisse in `_bmad-output/` stehen nie im Inventar.
**Jeder Ort, wer ihn anlegt und ob du ihn bearbeitest**
| Pfad | Angelegt von | Zum Bearbeiten für dich? | Hinweise |
| --- | --- | --- | --- |
| `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, `CONVENTIONS.md`, `.cursor/rules/bmad-plus.mdc`, `.codex/AGENTS.md`, `.opencode/AGENTS.md` | `install`, von `update` aufgefrischt | Nicht vorgesehen | Aus der Registry generiert. Änderst du eine, behält BMAD+ deine Version und frischt sie nicht mehr auf. Siehe die Seite zu den Adaptern. |
| `.agents/skills/` | `install`, `update` | Nein: gehört BMAD+ | Ein Ordner pro Agent (`agent-*`), pro Pack (`pack-`) und pro Skill (`bmad-plus-*`, `dev-studio`, `design`, ...). Geänderte Dateien bleiben als Konflikte erhalten. |
| `.agents/data/role-triggers.yaml` | `install`, `update` | Nein: gehört BMAD+ | Die Regeln zur automatischen Aktivierung von Agentenrollen. |
| `.agents/memory/` | `install` mit dem Memory-Pack; Agenten schreiben hinein | Ja | `decisions.md`, `lessons.md`, `patterns.md`, `context.md`, ein Ordner `sessions/` und ein Verweis `.brain-link` auf das genutzte Brain. Vorhandene Dateien werden nie überschrieben, `uninstall` behält den Ordner. |
| `_bmad/config.yaml` | `install` | Ja | Deine Einstellungen; siehe die Konfigurationsseite. Von `uninstall` behalten. |
| `_bmad/module.yaml`, `_bmad/module-help.csv` | `install`, `update` | Nein: gehört BMAD+ | Modulbeschreibung und Hilfeindex, im Inventar geführt. |
| `_bmad/.bmad-plus-install.json` | `install`, `update` | Nie von Hand | Das Manifest: Version, Packs, Tools, Sprache, Ausführungsmodus, Adapter-Fingerabdrücke und Datei-Inventar. Ist es unlesbar, kopiert `install` es nach `.bmad-plus-install.json.corrupt.bak`, bevor es repariert wird. |
| `_bmad/update-policy.json` | `update-policy` (wenn du eine Richtlinie speicherst) | Über den Befehl | Fehlt sie, gilt die Standardrichtlinie: notify. Eine ungültige Datei lässt die Update-Befehle die Arbeit verweigern. |
| `_bmad/review-rules.yaml`, `_bmad/assurance/`, `_bmad/ai-processing-register.yaml` | Du, oder `assurance init` und `ai-register init` | Ja | Die projekteigenen Review-Regeln, Assurance-Cases und das Register der KI-Integrationen. Keine davon existiert, bevor du sie anlegst. |
| `_bmad-output/discovery/`, `_bmad-output/build/` | `install` (leer) | Ja | Hier landen Produkt-Briefing, PRD, Architektur und Stories. Nie im Inventar, daher nie entfernt. |
| `_bmad-output/uat/` | `uat`-Befehle, Agenten | Specs und Triage: ja. Seiten: neu erzeugen | `specs/`, `pages/`, `results/`, `triage/`, `checks/` und `ORDER.md`. Ergebnisse stammen von den Testenden; bearbeite sie nicht. |
| `_bmad-output/review//` | `review`-Befehle | Nein: Belege | `scope.json`, `checklist.md`, `findings.json`, `findings.anchored.json`, `coverage.json`, `continue.json`, `compare.json` zu einem Review. |
| `_bmad-output/assurance/` | `assurance`-Befehle | Nein: Belege | Das per Hash verkettete Register (`runs.jsonl`) eines Assurance-Cases. |
| `_bmad-output/design/`, `_bmad-output/dev-studio/`, `_bmad-output/osint-reports/`, `_bmad-output/ready-to-integrate/` | Atelier und `intake`, Dev Studio, Shadow, Maker | Ja | Design-Briefings und -Reviews, Dev-Studio-Berichte (`.md`), OSINT-Dossiers und paketierte Agenten. Ein von `intake render` geschriebenes Briefing trägt eine Eigentumszeile und wird vom Befehl neu geschrieben: Bearbeite die Antworten, nicht das Briefing. |
| `.bmad/update-check.json` | `update-check` | Nie von Hand | Ein 24-Stunden-Cache der letzten Registry-Antwort, mit Wartezeit vor einem neuen Versuch nach einem Fehler. Gefahrlos löschbar: Er wird neu aufgebaut. |
| `.bmad/update.lock` | `install`, `update` (während sie laufen) | Nur wenn veraltet | Verhindert zwei gleichzeitige Installationen oder Updates. `doctor` meldet, wann sie veraltet ist (Besitzer weg oder älter als 60 Minuten), und nennt die zu löschende Datei. |
| `.bmad/updates//` | `update` | Nie von Hand | `receipt.json` und `backups/` eines Updates. Das liest `update --restore `; behalte sie, solange du zurückwollen könntest. |
| `.bmad/venv//` | `install --provision-python` | Nie von Hand | Die isolierte Python-Umgebung eines Packs, das eine braucht (SEO). |
| `.bmad/memory/` | `mem`-Befehle | Nie von Hand | `journal.ndjson`, `pattern-scores.json` und die Protokolle zu Promotionen und Ergebnissen: das Memory-Journal. |
| `.bmad-plus/swarm/runs//`, `.bmad-plus/swarm/reports/` | `swarm`-Befehle | Nie von Hand | Ein Ordner pro Schwarm-Lauf (Definition, Karten, Briefings, Antworten, Auszählung). Der Befehl schreibt nur unter diesem Baum. Füge Antworten mit `swarm save` hinzu. |
| `.bmad-plus/nexus/runs/` | `nexus`-Befehle | Nie von Hand | Der maßgebliche Zustand dauerhafter Task-Läufe. Daneben kann eine `.bmad-plus/orchestrator-state.yaml` liegen, nur als Navigationsübersicht. |
| `backups/` | Backup Manager (Backup-Pack) | Ja | ZIP-Archive des Projekts mit Zeitstempel. Das Backup-Pack schließt diesen Ordner aus seinen eigenen Archiven aus. |
| `~/.bmad-plus/brain/` | `install` mit dem Memory-Pack (wenn kein anderes Brain gefunden wird), `scan` | Ja | Außerhalb des Projekts, in deinem Home-Ordner: das globale Brain, das alle deine Projekte teilen. Von `uninstall` nie angefasst. |
## Was unter Versionskontrolle gehört
`install` ändert `.gitignore` nicht: Was du nicht ignorierst, erscheint in `git status`. Die Entscheidung liegt bei dir; die Tabelle oben liefert die Fakten dafür. Im aufgezeichneten Abnahmelauf ignorierte das Demoprojekt die installierten Pfade bereits, und `git status --short` blieb nach der Installation leer.
- Teilenswert mit dem Team: `_bmad/config.yaml` (gemeinsames Verhalten), `.agents/memory/` (gemeinsame Entscheidungen und Erkenntnisse), die Ergebnisse in `_bmad-output/` und `_bmad/update-policy.json`, wenn die Richtlinie eine Teamregel ist.
- Aus dem Paket reproduzierbar, daher kann ein Team sie lieber ignorieren: `.agents/skills/`, `.agents/data/`, die generierten Adapter-Dateien. Wer das Projekt klont, führt dann einmal `install` aus.
- Lokaler Zustand, der auf einem anderen Rechner nichts bedeutet: `.bmad/` und `.bmad-plus/`.
> **Hinweis · Das ist ein Vorschlag** Diese Aufteilung folgt dem Entstehen und Nutzen jedes Ortes; BMAD+ selbst schreibt keine Versionskontroll-Richtlinie vor.
## Was uninstall entfernt und behält
**Wirkung von uninstall**
| Entfernt | Behalten |
| --- | --- |
| Dateien, die byteweise dem entsprechen, was BMAD+ unter `.agents/skills/` und `.agents/data/` liefert, einschließlich der aus dem Design-Paket kopierten Skills | `.agents/memory/`, `_bmad/config.yaml`, `_bmad-output/`, jede geänderte Datei, jede Datei, die BMAD+ nicht geliefert hat |
| Die Moduldateien, das Installationsmanifest und die Adapter, die noch den Installationsmarker und einen passenden Fingerabdruck tragen (`AGENTS.md`, `CLAUDE.md`, ...) | `.bmad/`, `.bmad-plus/` (Lauf-Zustand und Belege) und `~/.bmad-plus/brain` |
| Leer gewordene Ordner werden entfernt; nichts wird rekursiv gelöscht | Alles unter einem symbolischen Link oder einer Junction: uninstall fasst verlinkte Pfade nicht an |
**Uninstall in der Praxis**
```text
$ npx bmad-plus uninstall --yes --directory .\demo-app
T BMAD+ Uninstaller
• BMAD+ v0.23.0 (installé le 2026-10-18)
• Packs sélectionnés: core, design
— La mémoire, les réglages et les fichiers inconnus ou modifiés ont été conservés.
# Die Zeile mit der Zahl entfernter Elemente fehlt absichtlich: Der erste aufgezeichnete Lauf, der einen Fehler aufdeckte, der die Design-Skills stehen ließ, zeigte eine Zahl, die nach der Korrektur nicht mehr gilt.
```
Ausgabe eines echten Laufs. Quelle: Aufgezeichnet in zwei Abnahmeläufen der 0.23.0 am 2026-10-18 (Kopfzeilen, dann die Erwartung von Schritt 7); der Installer lief auf Französisch
## Beispiel
### Lokalen Zustand aufräumen, ohne etwas Wichtiges zu verlieren
Der Projektordner ist nach Monaten voller Updates und Schwarm-Läufe unübersichtlich, und du willst wissen, was sich gefahrlos löschen lässt.
**In deinem KI-Assistenten**
```text
Liste auf, was unter .bmad und .bmad-plus in diesem Projekt liegt, sag, was jedes Element ist, und nenne, was ich löschen kann, ohne Projektgedächtnis, Einstellungen oder die Möglichkeit zu verlieren, ein Update wiederherzustellen.
```
**Das solltest du erhalten** Eine treffende Antwort trennt drei Gruppen. `update-check.json` ist ein Cache und wird beim nächsten Check neu aufgebaut. `updates//` enthält die Backups, die `update --restore` braucht; lösche nur Belege, zu denen du nie zurückkehrst. `update.lock` löschst du nur, wenn `doctor` ihn als veraltet meldet. `.bmad/memory/` enthält das Ereignisjournal und die Ergebnisse, die `mem recall` und `mem observe` lesen, und `swarm/runs/` und `nexus/runs/` sind die Belege vergangener Läufe: Lösche sie nur, wenn du diesen Verlauf und diese Belege nicht mehr brauchst. Das Markdown-Projektgedächtnis liegt in `.agents/memory/` und die Einstellungen in `_bmad/config.yaml`; nichts davon wird berührt.
**Siehe auch**
- [Die Konfigurationsdatei](https://bmad-plus.rochetta.fr/de/docs/reference/config-yaml/)
- [Adapter](https://bmad-plus.rochetta.fr/de/docs/reference/adapters/)
- [Installieren, aktualisieren, deinstallieren](https://bmad-plus.rochetta.fr/de/docs/guides/install-lifecycle/)
- [uninstall](https://bmad-plus.rochetta.fr/de/docs/reference/cli-uninstall/)
- [doctor](https://bmad-plus.rochetta.fr/de/docs/reference/cli-doctor/)
[BMAD+ Dokumentation](https://bmad-plus.rochetta.fr/de/docs/) · [Referenz](https://bmad-plus.rochetta.fr/de/docs/reference/)
[Quellcode auf GitHub](https://github.com/lrochetta/BMAD-PLUS)