# Die Registry und die Skills

> registry.yaml als einzige Quelle der Wahrheit: Pack-Felder, uses_skills, external_module, pipelines, intake, Prüfungen, Generiertes und wie ein Team mit Maker einen Agent oder ein Pack ergänzt.

Canonical: https://bmad-plus.rochetta.fr/de/docs/concepts/registry-and-skills/
Language: de
BMAD+ version: 0.23.1
Documentation reviewed: 2026-10-19
Author: Laurent Rochetta
License: MIT

BMAD+ Dokumentation › [Konzepte](https://bmad-plus.rochetta.fr/de/docs/concepts/) › Die Registry und die Skills

Hinter jeder Liste, Zahl und generierten Anweisungsdatei von BMAD+ steht eine einzige Datei: `registry.yaml` im Stamm des BMAD+-Quell-Repositorys. Sie deklariert die Packs, ihre Agenten, Skills, Datendateien, das Installationslayout, Laufzeiten und Compliance-Tags, die Adapter, die Datenverarbeitungs-Doktrin und mehr. Alles Nachgelagerte wird daraus generiert, sodass eine Liste, eine Zahl oder ein Adapter nicht von den Deklarationen abweichen kann. Diese Seite richtet sich an alle, die diesen Vertrag verstehen, die generierten Dateien mit Zuversicht lesen oder BMAD+ in einem Fork oder einer Team-Distribution erweitern wollen.

> **Hinweis · Eine Datei des Quell-Repositorys** Das npm-Paket liefert die generierten Ergebnisse (die Pack-Definitionen in der CLI, `module.yaml`, die Adapter) und die Generator-Skripte `tools/build/generate.js`, `generate-adapters.js` und `intake-contract.js`, aber nicht `registry.yaml` selbst. Ein installiertes Projekt enthält die Registry also nie; es enthält `AGENTS.md`, `_bmad/module.yaml` und die Skills. Um die Registry zu ändern, arbeitest du in einem Klon des BMAD+-Repositorys.

<a id="what-it-declares"></a>
## Was die Registry deklariert

**Abschnitte der obersten Ebene von registry.yaml**

| Abschnitt | Inhalt |
| --- | --- |
| `product` | Codename, Anzeigename, Version (gegen `package.json` geprüft), die BMAD-METHOD-Version, von der es abstammt, und ob der Upstream-Hinweis beibehalten werden muss. |
| `targets` | Die Rückgratdatei, der Integrationsvertrag (`execution: host-managed`, `lifecycle_events: not-integrated`), das optionale Prozess-Backend (`command`, `codex-exec`, Supervisor im Vordergrund, keine Zeitplanung), die sieben Adapter und die unterstützten Modellfamilien (`claude`, `gpt`, `gemini`, `local`). |
| `runtimes` | Node.js 20 oder neuer; Python 3.11 oder neuer mit `uv` und einem `pipx`-Fallback für die optionale Bereitstellung. |
| `memory` | Die Gedächtnisbereiche (Projektdateien, Portfolio) und die vier Leitplanken. |
| `eval` | Die Bewertungs-Gates (Replay bei Pull Requests; native Host-Läufe bei Modellwechseln). |
| `data_handling` | Die Doktrin hinter der Datenverarbeitungs-Seite: jeder Fluss, der die Maschine verlassen kann, mit seiner Einwilligungsgrundlage. |
| `packs` | Die zehn Packs und alles in der nächsten Tabelle. |

**Felder eines Packs**

| Feld | Was es deklariert |
| --- | --- |
| `order`, `display_name`, `cli`, `summary` | Installations- und Anzeigereihenfolge, Namen, die genauen Zeichenfolgen des Installers. Zahlen in einer Zusammenfassung werden über Platzhalter abgeleitet: Der Generator lehnt eine von Hand getippte Zahl von Agenten, Skills, Workflows oder Packs in diesen Feldern ab. |
| `required`, `runtime` | Core ist `required: true`. Die Laufzeiten, die ein Pack braucht (`node`, und `python` für SEO). |
| `agents`, `personas` | Die Agent-IDs, die der Installer registriert, und die sichtbare Persona jedes Agenten (Name, Rolle, Beschreibung). |
| `skills`, `data` | Skill-Verzeichnisse und Datendateien, die das Pack installiert. |
| `install_layout`, `pack_dir`, `doctor` | `loose` kopiert Agent-Verzeichnisse nach `.agents/skills/`; `packaged` kopiert ein Pack-Verzeichnis (`pack-<name>`), das seine Agenten enthält. `doctor` listet die Agent-Dateien und Pflichtressourcen, die `bmad-plus doctor` prüft. |
| `uses_skills` | Die Skill-IDs, die ein Pack oder eine Persona steuert (siehe unten). |
| `external_module` | Skills aus einem festgenagelten npm-Paket (siehe unten). |
| `pipelines` | Geordnete Schritte mit je einem Gate (siehe unten). |
| `intake` | Die Fragebogen-Datei des Packs (siehe die Intake-Seite). |
| `governance`, `required_keys`, `optional_keys` | Für OSINT: das Rechtsgrundlagen-Gate samt Vorlagen und die API-Schlüssel. |
| `cohabitation_warning` | Ein Satz dazu, wie sich das Pack mit einem anderen überschneidet. Der Installer zeigt ihn, und er wird als `- Cohabitation (<pack>): ...` unter den Registry-Fakten von Rückgrat und Adaptern ausgegeben. |
| `compliance_tags` | Rahmenwerke, auf die sich ein Pack bezieht (zum Beispiel GDPR und EU-AI-Act bei OSINT). |

<a id="uses-skills"></a>
## uses_skills: was ein Agent steuert

Ein Pack oder eine Persona listet die Skill-IDs, die sie steuert. Der Generator löst jede ID auf: Sie muss ein Skill eines beliebigen Packs, eines `external_module` oder von Core sein, und eine ID, die niemand liefert, lässt den Build scheitern. Die Rückgrat-Liste zeigt dann `- drives: design, design-review, redesign` hinter der Persona, und die generierten Anweisungen sagen dem Agent, vor dem Handeln das `SKILL.md` jedes gelisteten Skills zu lesen. Hier die echte Deklaration der Persona des Design-Packs.

**registry.yaml, Pack design (Auszug)**

```yaml
  design:
    order: 9
    display_name: "Design"
    required: false
    runtime: [node]
    agents: [design-engine]
    personas:
      - { id: design-engine, name: Atelier, role: Design Engine, description: "Senior product designer and design engineer: surfaces, tokens, accessibility, audits, redesigns", uses_skills: [design, design-review, redesign] }
    skills: []
    external_module: { package: design-skill, version: "0.2.1", skills: [design, design-review, redesign] }
    pack_dir: pack-design
    install_layout: packaged
    doctor:
      pack_agents: [design-engine.md]
      required_resources: [SKILL.md]
    intake: intake.yaml
    cohabitation_warning: "Overlaps Sentinel's UX-review role and Dev Studio's Rachel (UX Designer); ..."
```

<a id="external-module"></a>
## external_module: Skills aus einem npm-Paket

Ein Pack kann seine Skills aus einem veröffentlichten Paket statt aus dem BMAD+-Baum beziehen. Das Design-Pack ist das erste: Seine drei Skills stammen aus `design-skill`, festgenagelt auf die exakte Version `0.2.1`. Das Paket ist eine exakte Abhängigkeit von BMAD+ und steht in der Datenverarbeitungs-Doktrin. Beim Build löst der Generator das Paket auf, prüft, dass seine Version der deklarierten entspricht und dass `skills/<id>/SKILL.md` für jeden gelisteten Skill existiert. Bei der Installation löst BMAD+ das Paket aus seiner eigenen Installation auf, lehnt eine abweichende Version ab und kopiert nur das Verzeichnis `skills/` des Pakets nach `.agents/skills/<id>/`, über dieselbe verwaltete, hash-inventarisierte Kopie wie jede andere Datei (kein Symlink wird verfolgt). Der Tarball liefert außerdem ein Linker-Kommandozeilenwerkzeug, das BMAD+ nie ausführt. `bmad-plus doctor` verlangt die drei `SKILL.md`; die Deinstallation entfernt die kopierten Skills zusammen mit den übrigen verwalteten Dateien.

<a id="pipelines"></a>
## pipelines: geordnete Schritte mit Gate

Ein Pack kann Pipelines deklarieren: eine geordnete Abfolge seiner eigenen Workflows oder Agenten, jeder Schritt mit einem Gate (`require_approval`, `notify_only` oder `auto`). Nexus führt eine deklarierte Pipeline Schritt für Schritt mit dem konfigurierten Checkpoint-Verhalten aus, nach dem Intake des Packs. Pipeline-IDs müssen im Pack eindeutig sein, und jeder Schritt nennt genau einen `workflow` oder einen `agent`, der im Pack existiert. In 0.23.0 deklariert kein Pack eine Pipeline: Das Feld existiert, wird validiert und vom Autopilot verstanden und ist für Packs da, die es brauchen. Das Beispiel ist das Format aus der Spezifikation, kein mitgelieferter Inhalt.

**Format einer Pipeline nach der Spezifikation docs/specs/core-orchestration.md (eine Datei des Quell-Repositorys, nicht im npm-Paket enthalten)**

```yaml
pipelines:
  - id: full-build
    title: From interview to private preview
    steps:
      - { workflow: discovery, gate: require_approval }
      - { workflow: positioning, gate: require_approval }
      - { agent: brandsite-art, gate: notify_only }
      - { workflow: preview, gate: require_approval }
```

<a id="triggers"></a>
## Auslöser, die auf echte Dinge zeigen müssen

`.agents/data/role-triggers.yaml` steuert den Rollenwechsel. Die Prüfung `npm run check:triggers` (im Quell-Repository) validiert sie gegen die Registry: Ein Schlüssel der obersten Ebene muss ein Core-Agent-Kurzname (`strategist`, `architect-dev`, `quality`, `orchestrator`) oder eine Pack-ID sein; `default_role` muss einer der `auto_triggers` des Schlüssels sein; jede Rolle hat eine nicht leere `patterns`-Liste; `contexts` und `reasoning` sind, falls vorhanden, Listen von `snake_case`-Bezeichnern; unter einem Pack-Schlüssel ist jede Rollen-ID eine Persona- oder Pipeline-ID dieses Packs; und ein exakt wiederholtes Muster in zwei Rollen desselben Schlüssels ist ein Fehler. Drei Core-Kontexte verweisen auf die Funktionen dieser Seite: `swarm_declared` und `panel_requested` (Parallel Supervisor) sowie `pack_pipeline_declared` (Autopilot).

<a id="generated"></a>
## Was generiert wird und die Prüfungen, die es ehrlich halten

**Befehle in einer BMAD+-Quellkopie**

| Befehl | Was er tut |
| --- | --- |
| `npm run build` | Führt `tools/build/generate.js` aus und schreibt die Pack-Definitionen in `tools/cli/lib/packs.js` und `src/bmad-plus/module.yaml` aus der Registry. |
| `npm run build:check` | Scheitert, wenn die Registry diese beiden Dateien nicht mehr reproduziert, wenn `product.version` von `package.json` abweicht oder wenn ein deklarierter Pfad, Skill, externes Modul oder Intake falsch ist. |
| `node tools/build/generate-adapters.js --adopt` | Erzeugt `AGENTS.md` und die Adapter-Dateien neu (CLAUDE.md, GEMINI.md, .cursor-Regeln, .codex- und .opencode-Dateien, CONVENTIONS.md). `--check` prüft sie ohne zu schreiben. |
| `npm run check:counts` | Durchsucht die ausgelieferten Oberflächen nach von Hand getippten Zahlen („N agents“, „N workflows“, „N packs“) und scheitert an jeder, die dem widerspricht, was Registry und Dateien ergeben. Eine Zahl wird gegen ihr Subjekt geprüft: 38 stimmt für Dev-Studio-Workflows und ist für Agenten falsch. |
| `npm run check:triggers` | Validiert die Rollen-Auslöser wie oben beschrieben. |

<a id="skills-anatomy"></a>
## Was ein Skill ist

Ein Skill ist ein Ordner mit einer `SKILL.md`: einem Kopfbereich mit `name` und `description` (die sagt, wann er zu nutzen ist, in Worten, die dein Assistent erkennen kann), dann das Verfahren. Längeres Material liegt in einem Ordner `ref/` daneben, Vorlagen in `templates/`. Jeder Agent ist auch ein Skill: `agent-strategist/SKILL.md` ist Atlas. Der Host lädt das benötigte `SKILL.md`, deshalb zählt die Beschreibung: Sie lässt einen Assistenten den Skill wählen. Die sechs Core-Skills unten werden mit jeder Installation geliefert.

**Die Core-Skills**

| Skill | Was er tut | Gesteuert von |
| --- | --- | --- |
| `bmad-plus-autopilot` | Nexus führt Discovery, Build und Ship mit Checkpoints aus; zuerst der Intake jedes beteiligten Packs. | Nexus (AP) |
| `bmad-plus-parallel` | Erkennt unabhängige Aufgaben und überwacht sie (starten, beobachten, anhalten, neu starten, umverteilen, eskalieren); enthält den Schwarm-Abschnitt. | Nexus (PL) |
| `bmad-plus-swarm` | Moderator-Protokoll für Panel-, Jury- und Fanout-Schwärme im Budget. | Nexus Parallel Supervisor |
| `bmad-plus-intake` | Protokoll für `bmad-plus intake`: planen, wenige Fragen stellen, erfassen, rendern. | Jedes Pack mit Intake; Autopilot |
| `bmad-plus-uat` | Menschliches Abnahmeprotokoll: Spezifikation schreiben, Seite bauen, lesen, klassifizieren, Gate. | Sentinel (RB, RR, RG); Autopilot |
| `bmad-plus-sync` | Protokoll zur einmaligen Prüfung des installierten Rahmenwerks pro Sitzung; für Maintainer Pakete zur Prüfung von Upstream-Änderungen (keine automatische Upstream-Übernahme). | Alle; Maintainer |

Weitere Skills kommen mit ihren Packs: `dev-studio` (der Dispatcher des Packs), die aus `design-skill` kopierten Skills `design`, `design-review` und `redesign`, die Skills `bmad-osint-investigate` und `bmad-osint-investigator` des OSINT-Pakets. Die Packs SEO und Design tragen außerdem ein Router-`SKILL.md`, das reagiert, wenn du `/seo` oder `/design` in eine Nachricht schreibst; das sind Anfrage-Schlüsselwörter, keine von deinem Client registrierten Slash-Befehle.

<a id="extend-with-maker"></a>
## Einen Agent oder ein Pack mit Maker ergänzen

Maker ist der Agent Creator des Maker-Packs. Er entwirft mit dir einen Agent in vier Phasen (Discovery, Design mit deiner Freigabe, Generierung, Validierung) und schreibt ein Paket unter `_bmad-output/ready-to-integrate/`. Seine Fähigkeiten: `CA` Agent erstellen, `QA` Schnell-Agent mit weniger Fragen, `EA` das `SKILL.md` eines vorhandenen Agenten direkt an Ort und Stelle bearbeiten (ohne diesen Ordner), `VA` ein Agent-Paket validieren (Format, Manifest, eindeutige Fähigkeitscodes, Qualität der Auslöser), `PA` für die Integration verpacken, `TP` die Vorlage zeigen.

**Was Maker schreibt**

| Datei | Inhalt |
| --- | --- |
| `agents/agent-<name>/SKILL.md` | Der Agent: Überblick, Identität, Kommunikationsstil, Prinzipien, Fähigkeitentabelle mit Zwei-Buchstaben-Codes, Aktivierungsschritte. |
| `agents/agent-<name>/bmad-skill-manifest.yaml` | Name, Anzeigename, Titel, Icon, Fähigkeiten, Rolle, Identität, Pack, kanonische ID. |
| `pack-definition.yaml` | Ein fertig einfügbarer Ausschnitt für die Tabelle `packs:` der `registry.yaml` (Reihenfolge, Anzeigename, Icon, CLI-Eintrag, Laufzeit, Zusammenfassung, Agenten, Personas, Skills, Installationslayout, Compliance-Tags, benötigte Schlüssel). |
| `INTEGRATION.md` | Integrationsanleitung: zu kopierende Dateien, der zu ergänzende Registry-Eintrag, die Zeile für den Hilfe-Index, die Abfolge aus Neugenerierung und Prüfung, eine Test-Installation. |

> **Hinweis · Makers Integrationshinweis folgt der Registry** Das von Maker geschriebene `INTEGRATION.md` geht von der Registry aus: Es verlangt, den Eintrag aus `pack-definition.yaml` unter `packs:` in `registry.yaml` einzutragen, die daraus generierten Dateien nie zu bearbeiten (`tools/cli/lib/packs.js`, die Pack-Metadaten von `src/bmad-plus/module.yaml`, `AGENTS.md` und die übrigen Adapter), eine Zeile in `src/bmad-plus/module-help.csv` von Hand zu ergänzen, neu zu generieren und die Drift-Prüfungen auszuführen. Die folgenden Schritte entsprechen derselben Reihenfolge.

1. **Den Agent erstellen und validieren** Fordere `CA` bei Maker an, beantworte seine Discovery-Fragen, bestätige die Design-Tabelle und führe `VA` auf dem Ergebnis aus.
2. **In einen Klon des Repositorys kopieren** Lege den Agent-Ordner unter `src/bmad-plus/agents/` ab (loser Agent) oder in ein Pack-Verzeichnis (gepacktes Pack).
3. **In registry.yaml deklarieren** Ergänze oder erweitere ein Pack: `agents`, `personas` (mit `uses_skills`, falls es Skills steuert), `skills`, `install_layout`, `doctor` und bei Bedarf `intake`, `pipelines`, `cohabitation_warning`. Füge Rollen-Auslöser in `role-triggers.yaml` unter der Pack-ID hinzu, wenn du automatische Aktivierung willst.
4. **Neu generieren und prüfen** Führe `npm run build`, `node tools/build/generate-adapters.js --adopt`, dann `npm run build:check`, `npm run check:counts` und `npm run check:triggers` aus. Jeder Fehler nennt das zu korrigierende Feld.
5. **In einem Wegwerf-Projekt installieren** Führe den Installer aus deinem Klon mit `--packs core,<your-pack>` aus und danach `doctor`: Er darf keinen Fehler melden. Der Installationsvertrag des Repositorys (`npm run test:install-contract`) prüft dasselbe für jedes Pack.

In einem installierten Projekt kannst du ohne Klon trotzdem eigene Skill-Ordner unter `.agents/skills/` ablegen. BMAD+ behandelt Dateien, die es nicht installiert hat, als deine: `bmad-plus doctor` meldet sie als ohne Besitzer (eine Warnung, kein Fehler), und Update wie Deinstallation lassen sie stehen. Sie sind nicht in der Agent-Liste eingetragen, das Rückgrat erwähnt sie also nicht; ergänze eine Zeile in deiner eigenen Anweisungsdatei oder im Adapter, wenn der Assistent sie finden soll.

<a id="example-registry-ask-maker-agent"></a>
### Einen Team-Agent mit Maker entwerfen

Nutze es mit installiertem Maker-Pack. Das Paket wird nach `_bmad-output/ready-to-integrate/` geschrieben; sonst wird nichts geändert.

**In deinem KI-Assistenten**

```text
Maker, erstelle einen Kundensupport-Agent für unser Team: Er sortiert eingehende Tickets, entwirft Antworten in unserem Ton und eskaliert alles zur Abrechnung an einen Menschen. Stelle mir deine Discovery-Fragen in einem Block, zeige mir die Design-Tabelle (Name, Rollen, Fähigkeiten mit Zwei-Buchstaben-Codes, Auslöser, Abhängigkeiten) und warte auf meine Freigabe, bevor du generierst. Validiere dann das Paket und sage mir, was in der Registry noch zu deklarieren ist.
```

**Das solltest du erhalten** Ein Fragenblock, eine von dir freigegebene Design-Vorschau, dann `_bmad-output/ready-to-integrate/` mit dem `SKILL.md` des Agenten, seinem Manifest, einem Pack-Ausschnitt und einem Integrationshinweis, gefolgt von der Validierungs-Checkliste (Format, Manifestfelder, eindeutige Fähigkeitscodes, Qualität der Auslöser). Nichts wird installiert oder registriert, bevor du es tust.

**Siehe auch**

- [So funktioniert BMAD+](https://bmad-plus.rochetta.fr/de/docs/concepts/how-bmad-plus-works/)
- [Intake: erst fragen](https://bmad-plus.rochetta.fr/de/docs/concepts/intake/)
- [Das Maker-Pack](https://bmad-plus.rochetta.fr/de/docs/packs/maker/)
- [Das Design-Pack](https://bmad-plus.rochetta.fr/de/docs/packs/design/)
- [Referenz: Adapter](https://bmad-plus.rochetta.fr/de/docs/reference/adapters/)
- [Datenverarbeitung](https://bmad-plus.rochetta.fr/de/docs/security/data-handling/)

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

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