Jeder Schlüssel von _bmad/config.yaml: Ausführungsmodus, die vier Checkpoints, der uat-Block und das Schwarm-Budget. Standardwerte, wer was liest und was eine Änderung bewirkt.
_bmad/config.yaml ist die Datei, in der ein Projekt BMAD+ sagt, wie es sich verhalten soll: welche Sprache gilt, ob Agenten einzeln oder unter dem Orchestrator Nexus arbeiten, wo sie anhalten und auf dich warten müssen, wie menschliche Abnahmeprotokolle behandelt werden und wie viele Sub-Agenten ein Schwarm nutzen darf. bmad-plus install legt sie an; du kannst sie von Hand ändern. Diese Seite listet jeden Schlüssel, den sie schreibt.
Hinweis· Wer diese Datei liest
Die Kommandozeile selbst liest nur wenige Werte: den Block swarm (von bmad-plus swarm geprüft), fünf Textschlüssel für bmad-plus studio und communication_language für die Sprache einer von bmad-plus uat gebauten Abnahmeseite. Alles andere lesen die Agenten: Die Anweisungen ihrer Skills sagen ihnen, diese Datei zu öffnen und zu befolgen. Deshalb wirkt ein geänderter Checkpoint, sobald ein Agent das nächste Mal eine Pipeline startet, ohne dass ein Befehl nötig ist.
Die Datei nach install --yes --lang fr in einem Ordner namens demo-app, mit dem Paket 0.23.0 nachgespielt. Zeichenketten werden in einfachen Anführungszeichen geschrieben, und user_name fällt auf deinen Systembenutzernamen und dann auf Developer zurück
Die Werte für user_name, communication_language und project_name stammen aus dem Assistenten oder vom Ordner; der Rest sind die gezeigten Standardwerte. uat.environment enthält name: "TEST" und die Adresse, wenn du im Assistenten die URL einer Testumgebung eingegeben hast.
Antwort im Assistenten, sonst dein Systembenutzername, sonst Developer
CLI (studio) und Agenten
Der Name, mit dem Agenten dich begrüßen. Für studio muss es ein nicht leerer Text sein.
communication_language
Sprachname aus --lang, sonst Systemsprache, falls unterstützt, sonst English
CLI (studio, uat) und Agenten
Sprache, in der Agenten antworten. uat build öffnet die Abnahmeseite darin.
document_output_language
wie communication_language
CLI (studio) und Agenten
Sprache der Dokumente, die Agenten schreiben (Briefings, PRD, Berichte).
output_folder
_bmad-output
CLI (studio) und Agenten
Wohin Agenten ihre Ergebnisse legen. Für studio muss der Pfad relativ zum Projekt sein.
project_name
Name des Projektordners
CLI (studio) und Agenten
Der in Dokumenten verwendete Projektname.
execution_mode
manual
Agenten, über die Anweisungen ihrer Skills
manual: du rufst die Agenten. autopilot: Nexus führt Discovery, Build und Ship aus. hybrid: Autopilot mit häufigen Checkpoints. Wird bei der Installation mit --mode gesetzt.
auto_role_activation
true
Agenten, über die Anweisungen ihrer Skills
true: Ein Agent darf die Rolle wechseln, wenn der Kontext es verlangt, und kündigt es an. false: Rollen wechseln nur auf deine Bitte.
parallel_execution
true
Agenten, über die Anweisungen ihrer Skills
true: Der Parallel Supervisor darf unabhängige Aufgaben nebeneinander laufen lassen. false: nur nacheinander.
checkpoints.discovery
require_approval
Agenten, über die Anweisungen ihrer Skills
Halt nach Produkt-Briefing, PRD und UX-Review.
checkpoints.architecture
require_approval
Agenten, über die Anweisungen ihrer Skills
Halt nach der Architektur, vor jedem Code.
checkpoints.story
require_approval; notify_only, wenn mit --mode autopilot installiert
Agenten, über die Anweisungen ihrer Skills
Gilt nach jeder abgeschlossenen Story.
checkpoints.delivery
require_approval
Agenten, über die Anweisungen ihrer Skills
Gilt bei der finalen Lieferung. Mit uat.mode: gate wartet er außerdem auf ein bestandenes uat gate.
uat.mode
advisory
Agenten, über die Anweisungen ihrer Skills
advisory: Abnahmeseite bauen und anbieten, nie blockieren. gate: Die Lieferung wartet auf ein bestandenes Gate. off: kein Protokoll, und der Lieferbericht sagt das. Ein fehlender uat-Block bedeutet advisory.
uat.granularity
delivery
Agenten, über die Anweisungen ihrer Skills
delivery: ein Protokoll pro Lieferung. story: Die Seite wird sofort gebaut und geliefert, Story für Story.
uat.environment
name und url leer, oder TEST und deine URL
Agenten, über die Anweisungen ihrer Skills
Die Testumgebung, auf der das Protokoll durchgespielt wird.
uat.page_budget
max_steps: 15, max_minutes: 30
Agenten, über die Anweisungen ihrer Skills
Größenziel einer Abnahmeseite: höchstens so viele Schritte und Minuten für die testende Person.
uat.dir
_bmad-output/uat
Dokumentiert den Ort; bmad-plus uat nimmt ihn aus --dir
Ordner der Protokoll-Spezifikationen, Seiten, Ergebnisse und Triage. Der Standard ist derselbe Wert.
swarm.budget
26
CLI (swarm) und Agenten
Wie viele Sub-Agenten ein Schwarm-Lauf nutzen darf, bevor der Host dich fragen muss. Ganzzahl von 1 bis 1000.
swarm.wave
10
CLI (swarm) und Agenten
Wie viele Sub-Agenten gemeinsam gestartet werden. Ganzzahl von 1 bis 1000.
swarm.media_credits
ask
CLI (swarm) und Agenten
Einziger erlaubter Wert ist ask: Bezahlte Bild-, Video- oder Audioerzeugung deckt nie ein Budget ab, der Assistent fragt jedes Mal.
Ein Checkpoint ist eine Stelle in der Autopilot-Pipeline, an der der Orchestrator anhält, dich informiert und weitermacht oder einfach weitermacht. Jeder der vier Schlüssel nimmt einen von drei Werten.
Werte eines Kontrollpunkts
Wert
Verhalten
require_approval
Halt. Zeigt einen prüfbaren Checkpoint und wartet. Deckt eine frühere Freigabe von dir die konkrete nächste Aktion bereits ab, wird sie nicht erneut erfragt. Eine externe Benachrichtigung braucht einen konfigurierten Kanal und deine Freigabe.
notify_only
Berichtet den Fortschritt in der Sitzung und macht weiter.
auto
Macht automatisch weiter und protokolliert es für die Nachvollziehbarkeit.
Hinweis· Installieren mit --mode autopilot
Der einzige Checkpoint, der vom Modus bei der Installation abhängt, ist story: Er wird bei autopilot als notify_only, sonst als require_approval geschrieben. Spätere Änderungen an execution_mode schreiben die Checkpoints nicht um; ändere sie selbst.
Du vertraust der Pipeline bis zum fertigen Build und willst nur freigeben, was ausgeliefert wird.
In deinem KI-Assistenten
Setze in _bmad/config.yaml execution_mode auf autopilot, stelle die Checkpoints discovery, architecture und story auf notify_only und lass delivery auf require_approval. Zeig mir danach den geänderten Block.
Das solltest du erhalten Der Assistent ändert die Datei so, dass dort execution_mode: autopilot steht, die Punkte discovery, architecture und story auf notify_only und delivery auf require_approval stehen. Beim nächsten autopilot berichtet Nexus an den ersten drei Punkten und läuft weiter, und hält bei der Lieferung mit einem prüfbaren Checkpoint an.
Der Block swarm ist der Teil, den die CLI durchsetzt. Ein fehlender Block oder Schlüssel bedeutet die Standardwerte: 26 Sub-Agenten pro Lauf, 10 pro Welle. Verlangt bmad-plus swarm init mehr Einheiten als swarm.budget und fehlt --approved, schreibt es nichts und endet mit Code 2, damit ein Mensch entscheidet. Bezahlte Medienerzeugung liegt außerhalb jedes Budgets.
Ein Panel aus 30 simulierten Käufern wurde mit „needs approval“ abgelehnt, weil das Budget 26 beträgt; du beschließt, Panels bis 50 ohne Nachfrage zuzulassen.
In deinem KI-Assistenten
Setze in _bmad/config.yaml swarm.budget auf 50 und lass wave und media_credits unverändert. Starte danach dasselbe swarm init noch einmal ohne --approved.
Das solltest du erhalten Da 30 das Budget nicht mehr überschreitet, stoppt init nicht mehr mit Code 2: Es legt den Lauf an und gibt die Panel-Zeile aus (zum Beispiel „panel of 30 units, budget 50“). Eine Anfrage über 60 Einheiten würde weiter abgelehnt, bis du --approved angibst.
Bestehende Schlüssel gewinnen: Ein erneutes install überschreibt nie einen Wert, den du geändert hast.
Fehlende Schlüssel werden mit ihrem Standard ergänzt, auch fehlende Schlüssel innerhalb eines Blocks wie uat oder swarm. So erhält ein mit einer älteren Version installiertes Projekt die neueren Blöcke.
Antworten, die du ausdrücklich gibst, ersetzen den gespeicherten Wert: die Felder des Assistenten (Name, Kommunikationssprache, Ausführungsmodus), --mode und die URL einer Testumgebung.
Ändert sich etwas, wird die Datei von einem YAML-Schreiber unter der Kopfzeile „BMAD+ Project Configuration“ neu geschrieben. Von Hand ergänzte Kommentare bleiben in diesem Fall nicht erhalten.
Ist die Datei kein YAML-Mapping, lässt install sie unberührt und warnt: „_bmad/config.yaml could not be parsed; it was left unchanged.“
uninstall behält diese Datei, weil sie deine Einstellungen enthält.
_bmad/config.yaml: swarm.budget must be an integer from 1 to 1000.
budget (oder wave, gleiche Meldung mit seinem Namen) ist keine ganze Zahl im Bereich.
Schreibe eine einfache Ganzzahl, zum Beispiel budget: 50.
_bmad/config.yaml: swarm.media_credits must be "ask".
Es wurde ein anderer Wert geschrieben.
Setze media_credits: "ask" oder lösche die Zeile.
_bmad/config.yaml: swarm has an unknown key "<name>".
Im Block steht ein anderer Schlüssel als budget, wave, media_credits.
Entferne ihn oder korrigiere die Schreibweise.
_bmad/config.yaml is not valid YAML: …
Die Datei lässt sich nicht parsen.
Korrigiere die im Hinweis genannte Einrückung oder Anführungszeichen.
_bmad/config.yaml: user_name must be a nonempty string
studio verlangt, dass seine fünf Textschlüssel (user_name, communication_language, document_output_language, output_folder, project_name) nicht leere Zeichenketten sind, sofern vorhanden.
Gib dem Schlüssel einen Textwert oder lösche ihn, um den Standard zu nutzen.