Glossar
Jeder Begriff der BMAD+-Dokumentation in einfachen Worten, nach Themen: Host, Pack, Skill, Intake, Schwarm, Seed, Gate, Beleg, Protokoll und die Statuswörter der Tools.
Auf dieser Seite
- Architektur
- Dateien und Lebenszyklus
- Intake und Schwärme
- Orchestrierung
- Review und Abnahme
- Gedächtnis und Spezial-Packs
- Von den Werkzeugen gedruckte Statuswörter
Die Tabellen sind nach Themen statt alphabetisch gruppiert, damit verwandte Wörter beisammen stehen. Namen von Agenten, Befehlen, Optionen, Dateien und von den Werkzeugen gedruckte Statuswörter (wie needs-approval) bleiben in jeder Sprache englisch, denn das siehst du auf dem Bildschirm. Die rechte Spalte verweist auf die Seite, die den Begriff im Zusammenhang erklärt.
Architektur#
Begriffe der Architektur| Begriff | Bedeutung | Mehr dazu |
|---|
| Host | Das KI-Coding-Tool, das die Anweisungen liest und die Arbeit mit eigenem Modell und eigenen Berechtigungen erledigt: Claude Code, Cursor, Codex CLI und andere. | So funktioniert BMAD+ |
|---|
host-managed | Der Ausführungsvertrag von BMAD+: Der Host liefert Modell, Berechtigungen und etwaige Sub-Agenten; BMAD+ ruft kein Modell auf und lässt nichts im Hintergrund laufen. | So funktioniert BMAD+ |
|---|
| Rückgrat (Spine) | AGENTS.md, die eine generierte Anweisungsdatei, die alle Tools lesen: Agent-Liste, Skills, Gedächtnisregeln und Registry-Fakten. | So funktioniert BMAD+ |
|---|
| Adapter | Eine kurze generierte Datei im Format, das ein Tool erwartet (CLAUDE.md, GEMINI.md, eine Cursor-Regel, ...), die auf das Rückgrat verweist. | Adapter |
|---|
| Pack | Eine Gruppe aus Agenten, Skills und Workflows, die zusammen installiert werden. Es gibt zehn; Core ist Pflicht. | Alle Packs |
|---|
| Agent | Eine benannte Persona, die du im Chat ansprichst („Forge, ...“). 48 in den Packs, 15 davon Einstiegspunkte des Installers. | Die Agent-Liste |
|---|
| Rolle | Ein Modus innerhalb eines Agenten, etwa Analyst oder Product Manager bei Atlas. Der Wechsel wird angefordert oder ist automatisch und wird immer angekündigt. | Wie Rollen aktiviert werden |
|---|
| Persona | Die benannte Identität eines Agenten mit Name, Rolle und Beschreibung, wie in der Registry deklariert. | Registry und Skills |
|---|
| Skill | Ein Ordner mit einer SKILL.md, die der Host bei Bedarf lädt: ein Verfahren wie Autopilot, Intake oder Swarm. Jeder Agent ist auch ein Skill. | Registry und Skills |
|---|
| Workflow | Ein schrittweises Markdown-Verfahren in einem Pack, von deinem Assistenten ausgeführt. Dev Studio hat 38, Shield 11. | Dev Studio |
|---|
| Registry | registry.yaml, die einzige Quelle der Wahrheit im Quell-Repository, aus der Packs, Listen, Zahlen und Adapter generiert werden. | Registry und Skills |
|---|
| CLI | Das Kommandozeilenwerkzeug bmad-plus: deterministische Buchführung über lokale Dateien. Es ruft kein Modell auf und braucht Node.js 20 oder neuer. | Kommandozeilen-Referenz |
|---|
| Chat-Anweisung | Ein Satz für deinen Assistenten, etwa bmad-help, autopilot oder parallel. Kein Terminal-Befehl. | So funktioniert BMAD+ |
|---|
Dateien und Lebenszyklus#
Begriffe zu Dateien und Lebenszyklus| Begriff | Bedeutung | Mehr dazu |
|---|
| Manifest | _bmad/.bmad-plus-install.json: Version, Packs, Tools und der SHA-256 jeder installierten Datei. | Vertrauen und Eigentum |
|---|
| Besitz-Inventar | Das fileInventory des Manifests. Eine Datei gehört BMAD+, solange sie ihrem Hash entspricht; nach einer Bearbeitung ist sie deine. Sein Status ist complete, incomplete, legacy oder invalid. | Vertrauen und Eigentum |
|---|
| Beleg (receipt) | Die Aufzeichnung eines angewendeten Updates in .bmad/updates/<id>/receipt.json, mit Sicherungen, von update --restore genutzt. | Installieren, aktualisieren, deinstallieren |
|---|
| Update-Richtlinie | _bmad/update-policy.json: off, notify (Standard) oder auto mit ausdrücklichem Versionsbereich, dazu Kanal- und Vorabversions-Einstellungen. | BMAD+ im Team nutzen |
|---|
| Checkpoint | Ein Halt in einem Autopilot-Lauf, je Phase (discovery, architecture, story, delivery) auf require_approval, notify_only oder auto gesetzt. | Nexus |
|---|
| Ausführungsmodus | manual (du rufst jeden Agent), autopilot (Nexus steuert die Pipeline) oder hybrid (Autopilot mit häufigen Checkpoints). | Referenz: config.yaml |
|---|
| Ergebnis | Eine von einem Agent erzeugte Datei, meist unter _bmad-output/: ein Briefing, ein PRD, eine Architektur, Stories, ein Review, ein Bericht. | Deine erste Stunde |
|---|
| Nur-Prompts-Modus | Wie das SEO-Pack ohne nutzbare Python-Umgebung arbeitet: Der Agent folgt seinen Prompts, markiert unverifizierte Kategorien und berechnet keine Gesamtnote. | Das SEO-Pack |
|---|
Intake und Schwärme#
Begriffe zu Intake und Schwarm| Begriff | Bedeutung | Mehr dazu |
|---|
| Intake (Eingangsfragebogen) | Die Liste der Fragen, die ein Pack beantwortet haben muss, bevor es handelt, in einer intake.yaml definiert und von bmad-plus intake gesteuert. | Intake |
|---|
| Pflichtangabe (must-have) | Eine Frage, ohne die das Pack nicht starten kann: Sie muss beantwortet oder mit ihrem Risiko als unbekannt markiert sein. Sie darf keinen Standard tragen. | Intake |
|---|
answered, defaulted, unknown | Die drei Status einer Intake-Antwort: Du hast es gesagt; du hast den vorgeschlagenen Standard stehen lassen; du weißt es nicht (das Risiko wird kopiert). | Intake |
|---|
| Briefing (brief) | Zwei Bedeutungen. Ein Intake-Briefing ist das Markdown, das die CLI aus den Antworten erzeugt, der Vertrag für die weiteren Schritte des Packs. Ein Schwarm-Briefing ist die Datei, die ein Sub-Agent als gesamte Anweisung liest. | Intake |
|---|
| Schwarm (Swarm) | Viele Sub-Agenten, die je einmal dieselbe Art Arbeit leisten, gesteuert von bmad-plus swarm: ein Panel, eine Jury oder ein Fanout. | Schwärme |
|---|
| Sub-Agent | Eine vom Host gestartete Arbeitssitzung, eine je Briefing. BMAD+ startet sie nie; der Moderator tut es über den Host. | Schwärme |
|---|
panel, jury, fanout | Die drei Arten von Schwarm: aus einem Profil ausgeteilte Einheiten; gelistete Einheiten mit je einer Linse; gelieferte Einheiten mit disjunkten Schreib-Scopes. | Schwärme |
|---|
| Einheit, Karte (Card) | Eine Einheit ist ein Mitglied eines Schwarms. Ihre Karte sind ihre Daten (Segment, Alter, Einwand, Linse, Scope), beim Init ausgeteilt oder gelistet und für den Lauf eingefroren. | Schwärme |
|---|
| Profil, Definition, Vorlage, Kontext | Die vier Eingaben eines Schwarms: die Verteilung des Panels; das JSON, das Art, Antwortform und Auswertung deklariert; die Briefing-Vorlage; und der von den Einheiten gelesene Text (etwa ein Pitch), wörtlich eingebunden. | Schwärme |
|---|
| Seed | Eine Zahl von 0 bis 2147483647, die das Austeilen reproduzierbar macht: gleiches Profil, gleiches --n, gleicher Seed, gleiche Karten. | Schwärme |
|---|
| Budget, Welle | swarm.budget (26) ist, wie viele Sub-Agenten ein Lauf nutzen darf, bevor ein Mensch Ja sagen muss; swarm.wave (10), wie viele zusammen starten. | Schwärme |
|---|
| Freigabe | Das menschliche Ja, das einen Lauf über dem Budget erlaubt. Mit --approved erfasst; der Assistent darf es nicht von sich aus übergeben. | Schwärme |
|---|
| Offenlegungshinweis (Disclosure) | Der Satz, der jede Auswertung eröffnet, etwa „Simulated units are not people“. Einmal berichtet, vor jeder Zahl. | Schwärme |
|---|
| Auswertung (Tally) | tally.json und tally.md, nur über gültige Antworten berechnet, mit benannten übersprungenen Einheiten und sichtbarem Nenner. | Schwärme |
|---|
| gültige Antwort | Eine wohlgeformte Antwortdatei: richtige id, alle Pflichtfelder, kein nicht deklariertes Feld, Typen und Grenzen eingehalten. Gültig heißt wohlgeformt, nicht wahr. | Schwärme |
|---|
Orchestrierung#
Nexus-Begriffe| Begriff | Bedeutung | Mehr dazu |
|---|
| Autopilot | Der Nexus-Modus, der Discovery, Build und Ship mit Checkpoints abarbeitet. Gestartet, indem man im Chat autopilot sagt. | Nexus |
|---|
| Nexus-Lauf | Ein dauerhafter Aufgabengraph und seine Versuche, unter .bmad-plus/nexus/runs/ gespeichert und aus einem Plan erzeugt. | Nexus |
|---|
| Plan | Die JSON-Datei, die du für nexus create schreibst: Aufgaben mit Ziel, Scope, Artefakten, Ressourcen, Prüfungen und Grenzen. | Nexus |
|---|
| Aufgabe, Versuch | Eine Aufgabe ist ein Knoten des Plans. Ein Versuch ist ein Anlauf daran, an eine Identität gebunden (Host-Sitzung oder überwachter Prozess). | Nexus |
|---|
| Schreib-Scope | Die Dateien oder Ordner, die eine Aufgabe schreiben darf. Scopes sind exklusiv und über Aufgaben hinweg disjunkt. | Nexus |
|---|
| Ressource | Eine geschützte Eingabe einer Aufgabe (Anweisungen, ein Verifizierer), die Nexus hasht und die außerhalb jedes Schreib-Scopes liegen muss. | Nexus |
|---|
| Ausführung, Verifikation, Akzeptanz | Die drei getrennten Ergebnisse einer Aufgabe: Jemand hat die Arbeit getan; unabhängige Prüfungen bestanden; der aktuelle Arbeitsstand wurde akzeptiert. Jedes kann offen, bestanden, fehlgeschlagen oder mehrdeutig sein, ohne das nächste zu bedingen. | Nexus |
|---|
| abgleichen (reconcile) | Einen unsicheren Versuch mit einer Operator-Beobachtung schließen (Besitzer gestoppt, Wiederholung sicher oder nicht). Vor einer Wiederholung nötig. | Nexus |
|---|
| Prozess-Backend, Supervisor | Die optionale Möglichkeit, eine Aufgabe als lokalen Befehl oder Codex-CLI-Aufruf auszuführen. Der Supervisor ist der Vordergrundprozess, der sie startete und als Einziger seinem Kindprozess Signale senden darf. | Nexus |
|---|
Review und Abnahme#
Begriffe zu Review und Abnahme| Begriff | Bedeutung | Mehr dazu |
|---|
| Review-Scope | Die versiegelte, gehashte Liste der Dateien, die ein Review abdecken muss, mit benanntem Grund für jede ausgelassene Datei. Von review scope geschrieben. | Review und Abnahme |
|---|
| Befund (Finding), Verankerung (Anchor) | Ein Befund ist ein Problem, gemeldet mit dem Code, den er zitiert. Das Verankern lokalisiert das Zitat in der Datei (located, ambiguous oder unlocated); die Zeilennummer eines Modells wird nie geglaubt. | Review und Abnahme |
|---|
| Abdeckung (Coverage) | coverage.json: für jede ausgewählte Datei completed, failed oder waived mit Grund. Das Urteil leitet sich daraus ab. | Review und Abnahme |
|---|
| Gate | Ein Befehl, dessen Exit-Code ein Urteil ist: review gate (0 clean, 1 findings, 2 incomplete), uat gate (0 passed, 1 failed, 2 awaiting, 3 stale), assurance verify. | Review und Abnahme |
|---|
| Aufwand | --effort low|medium|high: die Zahl der Review-Durchgänge (1, 2 oder 3) und ob jeder Befund durch einen Widerlegungsschritt hinterfragt wird (nicht bei low). Ob der Reviewer das Lesen zuerst plant, hängt von der Größe der Änderung ab, nicht vom Aufwand. | Review und Abnahme |
|---|
| Review-Regel | Eine an Pfadmuster gebundene Markdown-Aufforderung; acht werden mit BMAD+ geliefert, Shield ergänzt sechs Compliance-Regeln, und ein Projekt ergänzt eigene in _bmad/review-rules.yaml. | Review und Abnahme |
|---|
| Abnahmeprotokoll (recette) | Eine eigenständige Seite, die ein Mensch Schritt für Schritt durchspielt, um eine Auslieferung auf dem Bildschirm zu bestätigen. Der Befehl ist bmad-plus uat (Alias recette). | Review und Abnahme |
|---|
| Zeuge (Witness) | Worauf ein Protokoll beruht (ein Datensatz, eine Datei, ein Zustand), deklariert mit der Nur-Lese-Abfrage, die seinen Zustand belegt. | Review und Abnahme |
|---|
| Lauf, Triage | Ein Lauf besteht aus den Antworten eines Testers als JSON. Die Triage ordnet jeden Fehler als product, recipe, data oder undecided ein, mit einer Entscheidung. | Review und Abnahme |
|---|
human-observed | Das Etikett der Abnahmebelege: Ein Mensch hat es gesehen. Das Gate stellt fest, dass der Lauf vollständig, aktuell und klassifiziert ist, nicht dass der Tester an der richtigen Stelle hinsah. | Review und Abnahme |
|---|
Gedächtnis und Spezial-Packs#
Begriffe zu Gedächtnis und Packs| Begriff | Bedeutung | Mehr dazu |
|---|
| Brain | Ein Ordner geteilten Gedächtnisses außerhalb eines Projekts: das globale Brain ~/.bmad-plus/brain/, ein Portfolio-_brain/ oder der Gedächtnisordner von Claude. Ein Projekt verknüpft sich damit; es wird nie kopiert. | Gedächtnis |
|---|
| Übergabe (Handoff) | Eine datierte Notiz in .agents/memory/sessions/, die zusammenfasst, was getan, entschieden und offen gelassen wurde, damit eine kalte Sitzung weitermachen kann. | Gedächtnis |
|---|
| Leitplanken G1 bis G4 | Vier Verhaltensregeln in den Anweisungen jedes Agenten: vor dem Coden nachdenken, Einfachheit zuerst, chirurgische Änderungen, zielgetriebene Ausführung. | Gedächtnis |
|---|
| Atelier, Design Read, Regler (Dials) | Atelier ist der Design-Agent. Das Design Read ist sein Intake. Die Regler (variance, motion, density, 1 bis 10) stimmen das Design ab; ein offener Regler wird aus der Oberfläche abgeleitet und als abgeleitet vermerkt. | Das Design-Pack |
|---|
| Rechtsgrundlagen-Gate (Phase minus 1) | Die OSINT-Regel, dass eine Operation zu einer namentlich genannten Person zuerst einen erfassten Zweck, eine Rechtsgrundlage, Aufbewahrung und einen Löschweg braucht. Ohne sie lehnt der Agent ab. | Vertrauen und Eigentum |
|---|
| Vertrauensstufe (A bis D) | Shadows Bewertung eines Fakts: A drei Quellen oder mehr, B zwei, C eine, D unverifiziert. | Das OSINT-Pack |
|---|
| Assurance Case, Hauptbuch (Ledger) | Shields Beleg-Werkzeuge: Behauptungen, jede gestützt auf eine ausgeführte Prüfung; ein hashverkettetes Hauptbuch runs.jsonl hält die Läufe fest. Eine Behauptung ist supported oder unsupported; passed, failed, stale und missing sind die Status einer Prüfung. | Das Shield-Pack |
|---|
| Kontrollen (Controls) | Compliance-Verweise der Form FRAMEWORK:ID, etwa ISO27001:A.8.5 oder GDPR:Art.32. Ein unbekanntes oder falsch geschriebenes Control wird abgelehnt. | Das Shield-Pack |
|---|
Von den Werkzeugen gedruckte Statuswörter#
Statuswörter und ihre Bedeutung| Wort | Gedruckt von | Bedeutung |
|---|
ready / not ready | intake plan | Jede Pflichtangabe ist beantwortet oder mit Risiko unbekannt / eine Pflichtangabe ist offen (Exit 2). |
|---|
needs-approval | swarm init | Der Lauf übersteigt das Budget und wurde nicht freigegeben (Exit 2); es wurde kein Briefing geschrieben. |
|---|
missing / invalid | swarm check | Keine Antwortdatei für eine Einheit / eine Antwortdatei, die die Validierung nicht besteht, mit Gründen. |
|---|
incomplete / findings / clean | review gate | Belege fehlen oder Review abgebrochen (2) / offene Befunde in einem abgedeckten Scope (1) / keine in einem abgedeckten Scope (0). |
|---|
passed / failed / awaiting / stale | uat gate | Abgeschlossener, aktueller, klassifizierter Lauf (0) / fehlgeschlagen (1) / kein abgeschlossener Lauf (2) / der Lauf beantwortete eine andere Revision (3). |
|---|
not started / running / completed | nexus summary | Der Ausführungszustand einer Aufgabe; verification und acceptance werden getrennt als pending, passed, failed oder accepted gezeigt. |
|---|
unknown / off / notify / auto | update-check, update-policy | Neueste Version nicht festgestellt (offline, veraltet) / Abfragen gestoppt / nur berichten / innerhalb eines ausdrücklichen Bereichs anwenden. |
|---|
ok / warning / error | doctor | Gesund / eine geänderte oder besitzerlose Datei, gemeldet / eine fehlende oder unlesbare Pflichtdatei (Exit 1). |
|---|