# Dev-Studio-Pack: sechs Personas und 38 Workflows

> Dev Studio deckt den Software-Lebenszyklus mit sechs Personas und 38 benannten Workflows ab, vom Produkt-Briefing bis zum Code-Review. Installation, Katalog nach Phase, Beispiele, studio-CLI, Grenzen.

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

BMAD+ Dokumentation › [Packs](https://bmad-plus.rochetta.fr/de/docs/packs/) › Dev-Studio-Pack: sechs Personas und 38 Workflows

Dev Studio gibt dir ein komplettes Software-Team in Form geschriebener Verfahren. Sechs Personas mit je einer Rolle führen 38 benannte Workflows in fünf Phasen aus: Analyse, Planung, Architektur, Umsetzung und Hilfsmittel. Du nennst die Persona oder den Workflow, und dein KI-Coding-Werkzeug liest die Anweisungen und führt sie mit seinen eigenen Werkzeugen aus. Es ist das Pack für ein bestimmtes, wiederholbares Verfahren (ein PRD validieren, eine Architektur schreiben, einen Fehler untersuchen) statt eines freien Gesprächs.

<a id="when-to-use"></a>
## Wann du es brauchst

- Du willst ein benanntes Verfahren mit definierter Eingabe und dokumentiertem erwartetem Ergebnis, das jedes Mal gleich abläuft.
- Du nutzt schon Core und willst feinere Rollen: etwa eine eigene UX-Designerin (Rachel) oder eine technische Redakteurin (Huldah).
- Eine gezielte Korrektur braucht nicht die ganze Pipeline: Der Orchestrator wählt den kleinsten Workflow, der das gewünschte Ergebnis liefert.

<a id="installed"></a>
## Was installiert wird

Dev Studio ist ein gepacktes Pack in `.agents/skills/pack-dev-studio/`, dazu der Dispatcher-Skill `dev-studio` in `.agents/skills/dev-studio/`. Das Pack enthält den Orchestrator `dev-studio-orchestrator.md`, den maschinenlesbaren `shared/catalog.json` (Personas, Workflows, Aliase, Eingabearten, benötigte Ressourcen), den Ausführungsleitfaden `shared/execution.md`, eine README und `categories/` mit einer Markdown-Datei je Persona und Workflow. Jeder Workflow hört auf mindestens drei Namen: `<id>`, `bmad-<id>` und `bmad-plus-<id>`, sodass `bmad-plus-validate-prd` und `validate-prd` dasselbe Verfahren erreichen.

<a id="personas"></a>
### Die sechs Personas

**Personas und die Workflows, die jede betreut**

| Persona | Rolle | Betreut |
| --- | --- | --- |
| Miriam (מרים) | Business Analyst | `product-brief`, `prfaq`, `market-research`, `domain-research`, `technical-research`, `party-mode`, `brainstorming`, `advanced-elicitation`, `bmad-help` |
| Huldah (חולדה) | Technical Writer | `document-project`, `distillator`, `editorial-review-prose`, `editorial-review-structure`, `shard-doc`, `index-docs` |
| Yosef (יוסף) | Product Manager | `create-prd`, `prd`, `edit-prd`, `validate-prd`, `adversarial-review` |
| Rachel (רחל) | UX Designer | `create-ux-design` |
| Bezalel (בצלאל) | System Architect | `create-architecture`, `create-epics-stories`, `implementation-readiness`, `generate-project-context`, `edge-case-hunter` |
| Oholiab (אהליאב) | Senior Engineer | `sprint-planning`, `create-story`, `dev-story`, `code-review`, `quick-dev`, `sprint-status`, `retrospective`, `correct-course`, `investigate`, `checkpoint-preview`, `qa-e2e-tests`, `customize` |

Eine Persona ist ein Satz Anweisungen, kein laufender Prozess. Wähle die Rolle, die die Aufgabe braucht; Atlas, Forge, Sentinel und Nexus aus Core können neben diesen sechs bestehen.

<a id="catalogue"></a>
### Die 38 Workflows nach Phase

Die Spalte Eingabe nennt, was ein Workflow braucht. Ein Anfrage-Workflow braucht deine Anfrage oder eine Datei. Ein Artefakt-Workflow braucht mindestens eine vorhandene Datei, etwa das zu validierende PRD. Ein Projekt-Workflow braucht eine Anfrage oder eine Datei und arbeitet am Projekt. Der Workflow bmad-help braucht nichts. Fehlender Kontext wird als benötigte Eingabe gemeldet, nicht geraten.

<a id="phase-analysis"></a>
### Analyse (6)

**Analyse-Workflows**

| Workflow | Persona | Eingabe | Erwartetes Ergebnis |
| --- | --- | --- | --- |
| `product-brief` | Miriam | Anfrage | Produktproblem, Zielgruppe und erster nützlicher Umfang |
| `prfaq` | Miriam | Anfrage | Vorgeschlagene Launch-Erzählung und die Fragen, die sie herausfordern |
| `document-project` | Huldah | Projekt | Dokumentation, die auf tatsächlich geprüften Projektdateien beruht |
| `market-research` | Miriam | Anfrage | Quellengestützte Analyse von Markt und Alternativen |
| `domain-research` | Miriam | Anfrage | Domänenbegriffe, Randbedingungen und Belegslücken |
| `technical-research` | Miriam | Anfrage | Machbarkeitsoptionen und eine konkrete nächste Prüfung |

<a id="phase-planning"></a>
### Planung (5)

**Planungs-Workflows**

| Workflow | Persona | Eingabe | Erwartetes Ergebnis |
| --- | --- | --- | --- |
| `create-prd` | Yosef | Anfrage | Prüfbare Anforderungen und Umfang |
| `prd` | Yosef | Anfrage | Auswahl zwischen PRD erstellen, ändern und validieren |
| `edit-prd` | Yosef | Artefakt | Nachvollziehbare Anforderungsänderungen |
| `validate-prd` | Yosef | Artefakt | Belegbasierte Feststellungen zu den Anforderungen |
| `create-ux-design` | Rachel | Anfrage | Nutzerabläufe, Interaktionszustände und Abnahmeprüfungen |

<a id="phase-architecture"></a>
### Architektur (4)

**Architektur-Workflows**

| Workflow | Persona | Eingabe | Erwartetes Ergebnis |
| --- | --- | --- | --- |
| `create-architecture` | Bezalel | Anfrage | Technische Entscheidungen, Grenzen und Abwägungen |
| `create-epics-stories` | Bezalel | Artefakt | Lieferbare Inkremente und umsetzbare Stories |
| `implementation-readiness` | Bezalel | Artefakt | Abstimmungslücken und Nachweise der Umsetzungsreife |
| `generate-project-context` | Bezalel | Projekt | Aktuelle Projektrandbedingungen mit Herkunft |

<a id="phase-implementation"></a>
### Umsetzung (11)

**Umsetzungs-Workflows**

| Workflow | Persona | Eingabe | Erwartetes Ergebnis |
| --- | --- | --- | --- |
| `sprint-planning` | Oholiab | Artefakt | Abgegrenzte Arbeit, Abhängigkeiten und Kapazitätsannahmen |
| `create-story` | Oholiab | Artefakt | Eine Story mit Kontext und Akzeptanzkriterien |
| `dev-story` | Oholiab | Artefakt | Umsetzung und Verifikation gegen eine Story |
| `code-review` | Oholiab | Projekt | Belegte Befunde oder ein Nullbefund-Bericht mit klarem Umfang |
| `quick-dev` | Oholiab | Projekt | Eine begrenzte Änderung mit angemessenen Prüfungen |
| `sprint-status` | Oholiab | Projekt | Fortschritt und Blocker, gestützt auf aktuelle Belege |
| `retrospective` | Oholiab | Artefakt | Lehren und umsetzbare Prozessänderungen |
| `correct-course` | Oholiab | Projekt | Eine begründete Reaktion auf eine wesentliche Änderung |
| `investigate` | Oholiab | Projekt | Hypothesen, Reproduktionsnachweise und nächste Aktion |
| `checkpoint-preview` | Oholiab | Projekt | Eine prüfbare Erklärung einer Änderung |
| `qa-e2e-tests` | Oholiab | Projekt | Passende automatisierte Prüfungen und Nachweise eines echten Laufs |

<a id="phase-utilities"></a>
### Hilfsmittel (12)

**Hilfs-Workflows**

| Workflow | Persona | Eingabe | Erwartetes Ergebnis |
| --- | --- | --- | --- |
| `distillator` | Huldah | Artefakt | Ein kompaktes Briefing mit Quellen und offengelegten Auslassungen |
| `party-mode` | Miriam | Anfrage | Verglichene Perspektiven und ein Entscheidungsprotokoll |
| `brainstorming` | Miriam | Anfrage | Unterscheidbare Optionen und ein kleines Experiment |
| `adversarial-review` | Yosef | Artefakt | Belegte Einwände, Widerlegungen und offene Fragen |
| `edge-case-hunter` | Bezalel | Anfrage | Konkrete Grenz- und Fehlerszenarien |
| `editorial-review-prose` | Huldah | Artefakt | Präzise Formulierungsverbesserungen |
| `editorial-review-structure` | Huldah | Artefakt | Eine leserorientierte Gliederung und Abschnittszuordnung |
| `advanced-elicitation` | Miriam | Anfrage | Geklärte Unsicherheiten und prüfbare Anforderungen |
| `shard-doc` | Huldah | Artefakt | Verlinkte Abschnitte mit Prüfung der Quellenabdeckung |
| `index-docs` | Huldah | Projekt | Ein Index der geprüften Dokumente |
| `bmad-help` | Miriam | keine | Passende Wege und ein begründeter nächster Schritt |
| `customize` | Oholiab | Projekt | Geprüfte Konfigurationsänderungen oder ausdrückliche Anweisungsänderungen |

<a id="quick-start"></a>
## Schnellstart

1. **Das Pack installieren** Core wird automatisch ergänzt; es zusätzlich zu nennen schadet nicht. Nötig ist nur Node.js 20.

   ```sh
   npx bmad-plus install --packs core,dev-studio
   ```
2. **Eine Persona einen Workflow ausführen lassen** Nenne die Persona und die Workflow-ID.

   ```sh
   Miriam, nutze product-brief, um ein kleines Werkzeug zur Ticket-Triage für unser Support-Team zu definieren.
   ```
3. **Optional: den Katalog im Terminal auflisten** Die CLI listet jeden Workflow mit Persona und Eingabeart auf und ändert nichts.

   ```sh
   npx bmad-plus studio list --json
   ```

<a id="examples"></a>
## Beispiele zum Kopieren

<a id="example-dev-studio-product-brief"></a>
### Miriam: ein Produkt mit product-brief definieren

Nutze es ganz am Anfang einer Idee. Eingabeart: Anfrage.

**In deinem KI-Assistenten**

```text
Miriam, nutze product-brief, um eine App mit Inspektions-Checklisten für unsere Techniker im Außendienst zu definieren. Sie arbeiten oft in Kellern ohne Netz: Sag, was das für den ersten Umfang bedeutet.
```

**Das solltest du erhalten** Ein Bericht mit Produktproblem, Zielgruppe und erstem nützlichen Umfang, standardmäßig nach `_bmad-output/dev-studio/product-brief.md` geschrieben.

<a id="example-dev-studio-document-project"></a>
### Huldah: ein bestehendes Projekt dokumentieren

Nutze es, wenn eine Codebasis keine brauchbare Dokumentation hat. Eingabeart: Projekt.

**In deinem KI-Assistenten**

```text
Huldah, führe document-project für dieses Repository aus. Dokumentiere nur, was du aus tatsächlich geöffneten Dateien belegen kannst, und liste auf, was du nicht prüfen konntest.
```

**Das solltest du erhalten** Dokumentation auf Basis geprüfter Projektdateien, mit offengelegten ungeprüften Punkten, gespeichert als `_bmad-output/dev-studio/document-project.md`, sofern du keinen anderen Ausgabeordner setzt.

<a id="example-dev-studio-validate-prd"></a>
### Yosef: ein PRD validieren

Nutze es, bevor die Architektur beginnt. Eingabeart: Artefakt, die Datei ist also Pflicht.

**In deinem KI-Assistenten**

```text
Yosef, führe validate-prd für docs/prd.md aus.
```

**Das solltest du erhalten** Belegbasierte Feststellungen zu den Anforderungen, jede an das gebunden, was die Datei tatsächlich sagt, in `_bmad-output/dev-studio/validate-prd.md`. Fehlt die Datei, meldet der Workflow, dass er eine Eingabe braucht.

<a id="example-dev-studio-ux-design"></a>
### Rachel: die Abläufe eines Onboardings entwerfen

Nutze es vor der visuellen Ebene. Ist das Design-Pack installiert, verantwortet Atelier die visuellen und Barrierefreiheitsregeln, und Rachels Abläufe speisen sein Intake.

**In deinem KI-Assistenten**

```text
Rachel, führe create-ux-design für das Onboarding neuer Nutzer aus: von der Kontoerstellung bis zur ersten gespeicherten Rechnung. Decke die Zustände leer, Fehler und offline ab.
```

**Das solltest du erhalten** Nutzerabläufe, Interaktionszustände und Abnahmeprüfungen in `_bmad-output/dev-studio/create-ux-design.md`.

<a id="example-dev-studio-architecture"></a>
### Bezalel: die Architektur entwerfen

Nutze es, sobald die Anforderungen feststehen. Der Workflow arbeitet schrittweise und kann an einem früheren Bericht anknüpfen.

**In deinem KI-Assistenten**

```text
Bezalel, entwirf die Architektur der in docs/prd.md beschriebenen Terminbuchungs-App. Halte jede Entscheidung mit Alternativen und Abwägungen fest.
```

**Das solltest du erhalten** Technische Entscheidungen, Grenzen und Abwägungen, festgehalten in `_bmad-output/dev-studio/create-architecture.md` mit der Architekturentscheidungs-Vorlage. Schließe `create-epics-stories` und `implementation-readiness` an, um die Stimmigkeit des Plans zu prüfen.

<a id="example-dev-studio-investigate"></a>
### Oholiab: einen Fehler reproduzieren, bevor er behoben wird

Nutze es bei Fehlern mit unklarer Ursache. Eingabeart: Projekt, mit der Beschreibung als Anfrage oder Datei.

**In deinem KI-Assistenten**

```text
Oholiab, nutze investigate, um den in docs/issue.md beschriebenen fehlschlagenden Import zu reproduzieren.
```

**Das solltest du erhalten** Hypothesen, Reproduktionsnachweise und die nächste Aktion in `_bmad-output/dev-studio/investigate.md`. Erst danach ergibt eine Korrektur Sinn, etwa mit `quick-dev`.

<a id="example-dev-studio-prepare-cli"></a>
### Ein schreibgeschütztes Kontextpaket im Terminal vorbereiten

Nutze es, um genau zu sehen, was ein Workflow erhält. Es bereitet vor und führt nicht aus: Die Arbeit macht weiterhin dein Assistent.

**In deinem KI-Assistenten**

```text
npx bmad-plus studio prepare validate-prd --input docs/prd.md --json
```

**Das solltest du erhalten** Ein schreibgeschütztes Paket: die aufgelöste Konfiguration, die mitgelieferten Anweisungstexte mit ihren SHA-256-Hashes, Inhalt und Hashes der Eingabedateien und der vorgeschlagene Berichtspfad. Eingabedateien müssen im Projekt liegen, und `--input` darf wiederholt werden. Fehlt eine erforderliche Eingabe (kein `--input` bei einem Workflow mit Artefakt-Eingabe), endet der Befehl mit Code 2 und dem Status needs-input, während ein nicht vorhandener `--input`-Pfad ein Fehler ist (Exit-Code 1); er schreibt nie das Ergebnis, führt keine Tests aus und bescheinigt nicht, dass ein Modell dem Workflow gefolgt ist.

<a id="example-dev-studio-help"></a>
### Fragen, welcher Workflow passt

Nutze es, wenn du das Ziel kennst, aber nicht den Workflow-Namen. bmad-help braucht keine Eingabe.

**In deinem KI-Assistenten**

```text
Miriam, führe bmad-help aus: Ich habe ein halb geschriebenes PRD und eine Deadline. Welche Dev-Studio-Workflows soll ich in welcher Reihenfolge ausführen, und welche kann ich überspringen?
```

**Das solltest du erhalten** Passende Wege und ein begründeter nächster Schritt. Bei einem halb geschriebenen PRD heißt das meist: zuerst die Anforderungen fertigstellen (`prd` oder `edit-prd`), dann `validate-prd`, dann `create-architecture`. Workflow-IDs in der Antwort sind Vorschläge, keine automatischen Auslöser.

<a id="outputs"></a>
## Was es schreibt und wo

Berichte landen standardmäßig in `_bmad-output/dev-studio/<workflow-id>.md`, angepasst an den konfigurierten Ausgabeordner. Codeänderungen bleiben im echten Projekt. Ein Bericht hält Umfang, Eingaben, Entscheidungen, erledigte Arbeit, Prüfungen, offene Fragen und die nächste Aktion fest. Beim Fortsetzen liest der Workflow den vorigen Bericht und prüft geänderte Eingaben erneut. Ein Bericht erlaubt nie, deine Änderungen zu überschreiben oder eine Veröffentlichung zu wiederholen.

**Aus _bmad/config.yaml gelesene Einstellungen (jeder Schlüssel hat einen Standardwert; project_name fällt auf den Ordnernamen zurück, hier demo-app)**

```yaml
user_name: user
communication_language: English
document_output_language: English
output_folder: _bmad-output
project_name: demo-app

```

Eine fehlende Datei ist gültig. Eine fehlerhafte Datei oder ein ungültiges bekanntes Feld ist ein Fehler. `project_name` ist standardmäßig der Ordnername. Deine aktuelle Anfrage und die Anweisungen deines Hosts haben Vorrang vor den Spracheinstellungen der Konfiguration.

<a id="data-and-prerequisites"></a>
## Datenflüsse und Voraussetzungen

Node.js 20 für den Installer und den optionalen Befehl `studio`. Kein Python, kein Schlüssel und kein eigener Datenfluss nach außen: `studio list` und `studio prepare` lesen nur lokale Dateien. Was dein Assistent an sein Modell sendet, hängt von deinem Host-Werkzeug ab. Recherche-Workflows brauchen zugängliche Quellen für aktuelle Tatsachenbehauptungen und sagen es, wenn sie keine haben.

<a id="limits"></a>
## Grenzen und Stolpersteine

> **Warnung · Eine Rolle, kein Scheduler** Der Orchestrator ist eine Anweisungsrolle. Er sendet keine Benachrichtigung, macht keinen Commit und veröffentlicht nichts von selbst. Unabhängige parallele Agenten, Browsen und Befehlsausführung hängen von deinem Host ab; spielt ein Assistent mehrere Perspektiven, muss er das sagen, und nicht verfügbare Prüfungen bleiben sichtbar. Kein Workflow garantiert fehlerfreien Code oder eine verlustfreie Zusammenfassung.

> **Hinweis · Kein BWML-Interpreter** Die ältere XML-artige Workflow-Notation (BWML) und die TOML-Anpassung haben in diesem Pack weder Interpreter noch Resolver. Eine Migrationsnotiz im Pack beschreibt das unterstützte Ersatzverhalten: einfache Markdown-Verfahren, den Katalog und `_bmad/config.yaml`.

> **Tipp · Überschneidung mit Core und Design** Dev Studio überschneidet sich mit Atlas, Forge, Sentinel und Nexus; beide können nebeneinander bestehen, wähle also die Persona, deren Workflow du willst. Bei Bildschirmen betreut entweder Rachel oder Atelier einen bestimmten Bildschirm, und die Übergabe sagt, wer.

> **Hinweis · Herkunft** Dev Studio ist ein eigenes Pack von Laurent Rochetta: sechs spezialisierte Agenten für den Software-Lebenszyklus und 38 Workflows, als eigene BMAD+-Anweisungen geschrieben. Persona-Namen und Workflow-Herkunft würdigen BMAD-METHOD von BMad Code, LLC (MIT-Lizenz, Basis v6.6.0); es wird keine Upstream-Laufzeit mitgeliefert.

**Siehe auch**

- [Alle zehn Packs im Vergleich](https://bmad-plus.rochetta.fr/de/docs/packs/packs-overview/)
- [Core-Pack](https://bmad-plus.rochetta.fr/de/docs/packs/core/)
- [Design-Pack (Atelier)](https://bmad-plus.rochetta.fr/de/docs/packs/design/)
- [Referenz des Befehls studio](https://bmad-plus.rochetta.fr/de/docs/reference/cli-studio/)
- [Liste aller 48 Agenten](https://bmad-plus.rochetta.fr/de/docs/agents/agents-roster/)

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

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