# Intake: erst fragen, dann handeln

> Warum ein Pack vor dem Handeln fragt, wie ein intake.yaml seine Fragen Feld für Feld festlegt, wie Antworten einen Status erhalten, und ein komplettes Design Read mit echter Ausgabe.

Canonical: https://bmad-plus.rochetta.fr/de/docs/concepts/intake/
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/) › Intake: erst fragen, dann handeln

Ein Intake ist die Liste der Fragen, die ein Pack beantwortet haben muss, bevor es zu arbeiten beginnt. Ohne ihn füllt ein Agent bei einer dünnen Anfrage die Lücken mit Vermutungen, und du merkst es erst im Ergebnis. Mit ihm stellt der Agent wenige Fragen auf einmal, in deiner Sprache, hält jede Antwort mit ihrem Status fest und erzeugt ein Briefing, das zum Vertrag für alles wird, was das Pack danach tut. Lies diese Seite, wenn du ein Pack mit Intake nutzt (in 0.23.0 das Design-Pack) oder deinem eigenen Pack einen geben willst.

<a id="video-ask-then-swarm"></a>
Video: [Erst fragen, dann der Schwarm](https://bmad-plus.rochetta.fr/media/ask-then-swarm-en.mp4) — Die Intake-Fragen, das Budget von 26 und die Freigabe, Wellen von Sub-Agenten und eine Auswertung, die klarstellt, dass simulierte Einheiten keine Menschen sind.
[Untertitel (WebVTT)](https://bmad-plus.rochetta.fr/media/ask-then-swarm-de.vtt)

Transkript:

> Bevor ein Pack handelt, fragt es. Der Intake stellt jeweils ein paar Fragen und markiert die Pflichtfragen. Wo du keine Antwort hast, schlägt es einen Standardwert vor oder hält die Frage als unbekannt fest, samt Risiko. Die Antworten werden zu einem Briefing, und nichts darin ist erfunden. Dann der Schwarm. Standardmäßig darf ein Lauf 26 Sub-Agenten nutzen, bevor der Assistent dich fragen muss. Willst du mehr, wartet der Lauf mit dem Status needs-approval, bis ein Mensch zustimmt. Nach der Freigabe arbeiten die Sub-Agenten standardmäßig in Wellen von zehn, jeder liest ein Briefing und schreibt eine Antwort. Die Laufzeit prüft jede Antwortdatei und zählt nur die gültigen. Diese Auswertung besteht aus Demodaten und beginnt mit ihrem Hinweis: Simulierte Einheiten sind keine Menschen. Lies die Raten als Obergrenze und bestätige sie mit echten Menschen.

Transkript mit Bildbeschreibung:

- **0:00** Im Bild: Ein einzelner bernsteinfarbener Lichtpunkt in einer dunklen blaugrünen Wolke, von dem schwache Strahlen ausgehen. Die Einblendung lautet auf Englisch „Ask first“. Sprechtext: Bevor ein Pack handelt, fragt es.
- **0:04** Im Bild: Ein Terminalfenster mit dem Titel „~/app“. Es wird der Befehl bmad-plus intake plan getippt, mit der intake.yaml des Packs Design und einer Antwortdatei. Das Bild zoomt auf das Ergebnis: „design-read (design): not ready — 0 answered, 0 defaulted, 0 unknown“ und, orange umrahmt, „Must-haves still open: surface_kind, audience, job“. Darunter der erste Block von Fragen (höchstens 6 pro Nachricht), jeweils mit Typ und dem Vermerk „must-have“, wo er zutrifft: surface_kind, audience, job, brand_assets, design_system und aesthetic_family. Dann wird bmad-plus intake record getippt, mit drei Antworten (surface_kind=dashboard; audience=„Accountants in a practice, on a desktop, at month end“; job=UNKNOWN) und einem Standardwert für design_system. Der nächste Block von Fragen erscheint: brand_assets, aesthetic_family, variance, motion, density und stack. Der Bildschirm endet auf einer gelben, umrahmten Zeile: „Unknown: job — risk: There is no goal to review against, so hierarchy and the primary action cannot be judged, only decorated.“ Der gesamte Terminaltext ist englisch. Sprechtext: Der Intake stellt jeweils ein paar Fragen und markiert die Pflichtfragen. Wo du keine Antwort hast, schlägt es einen Standardwert vor oder hält die Frage als unbekannt fest, samt Risiko.
- **0:19** Im Bild: Zwei Terminalbereiche. Links wird bmad-plus intake render getippt; es gibt „Brief written to _bmad-output/design/brief.md (3238 bytes); the intake is ready.“ aus. Der rechte Bereich öffnet brief.md und scrollt hindurch. Unter Überschriften wie „Who and why“ erscheint jede Frage mit ihrer Antwort („dashboard“; „Accountants in a practice, on a desktop, at month end“) oder mit „Answer: not asked yet.“ und einer Zeile „Feeds: brief.md#…“. Das Scrollen hält bei einer Überschrift an, „Open questions“. Der erste Eintrag ist umrahmt: „job (must-have): unknown — risk: There is no goal to review against, so hierarchy and the primary action cannot be judged, only decorated.“ Darunter eine Liste weiterer Einträge, alle mit „not asked yet“ markiert: brand_assets, aesthetic_family, variance, motion, density, stack, accessibility_target, languages und weitere. Sprechtext: Die Antworten werden zu einem Briefing, und nichts darin ist erfunden.
- **0:29** Im Bild: Ein Terminal. Der Befehl bmad-plus swarm init wird getippt, mit einer Schwarmdefinition, einem Profil, einer Kontextdatei, 40 Einheiten (--n 40) und dem Seed 7, gefolgt von einem Echo des Exit-Codes. Die Ausgabe: „buyer-panel-20261018-asuq: needs approval.“ (die Wörter „needs approval“ sind umrahmt) „The run needs 40 sub-agents and the budget is 26: ask the user, then re-run init with --approved --seed 7.“ und „exit code: 2“ (umrahmt). Derselbe Befehl wird noch einmal mit --approved ausgeführt. Das Bild zoomt auf das Ergebnis, wobei „panel of 40 units“ umrahmt ist: „buyer-panel-20261018-zho8: panel of 40 units, budget 26, approval user. Seed 7 (same seed, same cards).“ und „Next: bmad-plus swarm briefs buyer-panel-20261018-zho8“. Der gesamte Terminaltext ist englisch. Sprechtext: Dann der Schwarm. Standardmäßig darf ein Lauf 26 Sub-Agenten nutzen, bevor der Assistent dich fragen muss. Willst du mehr, wartet der Lauf mit dem Status needs-approval, bis ein Mensch zustimmt.
- **0:46** Im Bild: Bernsteinfarbene Partikel schießen aus einem hellen Zentrum und bilden vor einem dunkelvioletten Hintergrund einen sich weitenden Ring. Die Einblendung lautet auf Englisch „Waves of 10“. Sprechtext: Nach der Freigabe arbeiten die Sub-Agenten standardmäßig in Wellen von zehn, jeder liest ein Briefing und schreibt eine Antwort.
- **0:56** Im Bild: Ein Terminal. bmad-plus swarm briefs buyer-panel-20261018-zho8 gibt „40 of 40 units need a sub-agent, in waves of 10.“ aus und listet die Briefings Welle für Welle auf, jeweils mit dem Pfad einer Briefing-Datei (B001.md, B011.md, B021.md, B031.md). Darunter stehen die Anweisung „Each sub-agent: Read the brief and follow it exactly; it is your whole instruction.“ und der Offenlegungshinweis „Simulated units are not people. Read rates as an upper bound and confirm with real ones.“ Dann gibt bmad-plus swarm check „8 of 40 valid answers.“ aus und listet die Probleme: „B009 invalid: field "buys" must be true or false“ (umrahmt), „B010 missing: no answer file“, „B011 missing: no answer file“ und „B012 … B040 (missing)“. Sprechtext: Die Laufzeit prüft jede Antwortdatei und zählt nur die gültigen.
- **1:07** Im Bild: Zwei Terminalbereiche. Links wird bmad-plus swarm tally buyer-panel-20261018-zho8 getippt; es gibt den Pfad von tally.md, „8 of 40 units counted; 32 skipped.“ und die Zeile „Disclosure:“ aus. Der rechte Bereich öffnet tally.md und scrollt durch kurze zitierte Antworten, nach Segment (mid career, high earner) und Verhalten (occasional, explorer, daily regular) gruppiert, und hält dann bei „Numbers: price_floor“ an: eine Tabelle mit den Spalten group, count, median, mean, min und max. Die erste Zeile, „all“, zeigt 8, 3.65, 3.7, 3 und 4.5. Es folgen Zeilen für drei Segmente und drei Verhaltensweisen. Sprechtext: Diese Auswertung besteht aus Demodaten und beginnt mit ihrem Hinweis: Simulierte Einheiten sind keine Menschen.
- **1:16** Im Bild: Unter Wasser: Viele durchscheinende Blasen treiben in blauem Licht, und zwei von ihnen leuchten bernsteinfarben und nähern sich, bis sie sich überlappen. Die Einblendung lautet auf Englisch „Simulated units are not people.“ Sprechtext: Lies die Raten als Obergrenze und bestätige sie mit echten Menschen.

<a id="why-ask-first"></a>
## Warum zuerst fragen

Ein Pack handelt nach dem, was es weiß. Einen Bildschirm für „ein Dashboard“ zu entwerfen, ohne zu wissen, wer es nutzt, auf welchem Gerät und für welche Aufgabe, ergibt eine generische Vorlage, die niemandem passt. Die Kosten der fehlenden Antwort zeigen sich erst, wenn die Arbeit getan ist. Ein Intake zieht diese Kosten nach vorn: Jede Frage sagt, ob das Pack ohne sie starten kann, was es vorschlägt, wenn es dir egal ist, und was schiefgeht, wenn du es nicht weißt.

Drei Dateien sind beteiligt. Der Intake (`intake.yaml`) wird mit dem Pack geliefert. Die Antwortdatei ist JSON und wird nur von `bmad-plus intake record` geschrieben. Das Briefing ist Markdown und wird nur von `bmad-plus intake render` geschrieben. Dein Assistent stellt die Fragen; der Befehl fragt nie etwas und ruft kein Modell auf.

<a id="three-statuses"></a>
## Jede Antwort hat einen Status

**Die drei Status, und keine weiteren**

| Status | Bedeutung | Wie es erfasst wird | Wie das Briefing es zeigt |
| --- | --- | --- | --- |
| `answered` | Du hast es gesagt. | `--set id=VALUE` | `Answer:` gefolgt vom Wert |
| `defaulted` | Du hast den vom Pack vorgeschlagenen Standardwert stehen lassen. Das ist ein Vorschlag, keine Tatsache, die du genannt hast. | `--default id` | `Answer (proposed default, not confirmed by the user):` |
| `unknown` | Du weißt es nicht. Das Risiko der Frage wird mit der Antwort kopiert und reist so ins Ergebnis mit. | `--set id=UNKNOWN` | `Answer: unknown`, dann das Risiko und eine Zeile unter „Open questions“ |

Das Pack ist bereit, wenn jede Pflichtfrage (must-have) beantwortet oder mit ihrem Risiko als unbekannt markiert ist. „Bereit“ heißt nicht, dass die Risiken verschwunden sind: Das Briefing listet sie unter „Open questions“, und ein Ergebnis, das auf einem unbekannten must-have beruht, soll das Risiko im ersten Absatz wiederholen. Einen Wert, den du selbst gewählt hast, erfasst du mit `--set`, auch wenn er dem Standard entspricht; `--default` heißt nur „ich akzeptiere deinen Vorschlag“.

<a id="intake-file"></a>
## Die Datei intake.yaml, Feld für Feld

Der Validator ist streng: Ein unbekanntes Feld, ein falscher Typ oder eine verletzte Regel ist ein Fehler und wird nie stillschweigend ignoriert. Derselbe Validator läuft bei `bmad-plus intake check` und beim Bau von BMAD+ selbst.

**Felder der obersten Ebene und der Abschnitte**

| Feld | Pflicht | Regel |
| --- | --- | --- |
| `schema_version` | ja | Muss `1` sein. |
| `id` | ja | Ein kleingeschriebener Slug, der mit einem Buchstaben beginnt (Buchstaben, Ziffern, Bindestriche). Benennt den Intake; die Antwortdatei verweist darauf. |
| `pack` | ja | Ein kleingeschriebener Slug: die ID des Packs, zu dem der Intake gehört. |
| `title` | ja | Nicht leerer Text. Wird zur ersten Zeile des Briefings. |
| `language` | nein | `user` (in der Sprache des Nutzers fragen, der Standard) oder ein Tag wie `fr` oder `en-GB`. |
| `max_per_message` | nein | Ganzzahl von 1 bis 20; 6, wenn nicht angegeben. Die höchste Zahl Fragen in einer Nachricht. |
| `sections` | ja | Nicht leere Liste von Abschnitten. Jeder hat eine `id` (Slug, eindeutig), einen `title` und eine nicht leere Liste `questions`. |

**Felder einer Frage**

| Feld | Pflicht | Regel |
| --- | --- | --- |
| `id` | ja | snake_case, beginnt mit einem Buchstaben, in der ganzen Datei eindeutig (nicht nur im Abschnitt). |
| `ask` | ja | Die Frage, wie der Assistent sie stellen wird. Schreibe sie so, wie du einen Menschen fragen würdest. |
| `kind` | ja | `text`, `choice`, `number`, `boolean` oder `list`. |
| `choices` | bei `choice` | Mindestens zwei verschiedene nicht leere Werte. Bei jedem anderen Typ abgelehnt. |
| `min`, `max` | nein | Grenzen einer `number`. Bei jedem anderen Typ abgelehnt; `min` darf `max` nicht übersteigen. |
| `default` | nein | Ein für den Typ gültiger Wert. Bei einer Pflichtfrage verboten: Der Nutzer antwortet selbst. |
| `must_have` | nein | `true`, wenn das Pack ohne Antwort oder ausdrückliches „unbekannt“ nicht starten kann. |
| `risk_if_unknown` | bei must-have | Was schiefgeht, wenn die Antwort unbekannt bleibt. Pflicht, wenn `must_have` true ist; sonst erlaubt. |
| `feeds` | nein | Liste von Artefakt-Ankern wie `brief.md#audience`. Informativ: Sie sagt einem Leser, welchen Teil der Arbeit die Antwort speist. |

**Typen und wie ein Wert auf der Kommandozeile eingegeben wird**

| Typ | Akzeptierter Wert | Grenzen |
| --- | --- | --- |
| `text` | Jeder nicht leere Text; Zeilenumbrüche und Tabs erlaubt, andere Steuerzeichen abgelehnt. | Höchstens 4000 Zeichen. |
| `choice` | Genau einer der aufgeführten `choices`. | Alles andere wird mit der Liste gültiger Werte abgelehnt. |
| `number` | Eine endliche Zahl, innerhalb von `min` und `max`, wenn gesetzt. | Außerhalb des Bereichs wird abgelehnt. |
| `boolean` | `true`, `yes`, `y` oder `1` für wahr; `false`, `no`, `n` oder `0` für falsch. | Alles andere wird abgelehnt. |
| `list` | Einträge, durch Kommas getrennt: `--set "highlights=faster install, new swarm command"`. | Nicht leer; höchstens 50 Einträge. |

<a id="the-loop"></a>
## Die Schleife: Plan, Frage, Erfassen, Rendern

1. **Planen** Der Befehl listet die nächsten Fragen: zuerst die Pflichtfragen, dann die übrigen in Dateireihenfolge, höchstens `max_per_message`. Er endet mit 0, wenn alles bereit ist, und mit 2, solange ein must-have offen ist.

   ```sh
   npx bmad-plus intake plan --intake FILE --answers FILE
   ```
2. **Fragen** Der Assistent stellt diese Fragen in einer Nachricht, in deiner Sprache, mit Auswahl oder Grenzen, und schlägt den Standardwert vor, wenn es einen gibt. Er bläht die Nachricht nicht auf und fragt nicht nach, was schon erfasst ist.
3. **Erfassen** Jede Antwort wird gegen Typ und Grenzen der Frage geprüft und abgelehnt, wenn sie nicht passt (nichts wird geschrieben). `UNKNOWN` erfasst das Risiko; `--default` erfasst den Vorschlag. Eine Frage lässt sich pro Aufruf nur einmal setzen.

   ```sh
   npx bmad-plus intake record --intake FILE --answers FILE --set id=VALUE --default other_id
   ```
4. **Wiederholen, bis es bereit ist** Plane erneut. Sobald es ready meldet, wird nicht mehr gefragt, auch wenn optionale Fragen offen sind: Der Assistent nennt die offenen und macht weiter, außer du möchtest fortfahren.
5. **Das Briefing rendern** Das Briefing listet jeden Abschnitt und jede Antwort mit Status, danach die offenen Fragen mit ihren Risiken. Es ist die Eingabe für den nächsten Schritt des Packs.

   ```sh
   npx bmad-plus intake render --intake FILE --answers FILE --out brief.md
   ```

<a id="design-read"></a>
## Ein vollständiges Beispiel: das Design Read des Design-Packs

Der einzige in 0.23.0 gelieferte Intake gehört zum Design-Pack. Atelier, sein Agent, führt ihn vor jeder Designarbeit aus (`/design read`). Er hat 13 Fragen in 5 Abschnitten, 3 davon Pflicht: die Oberfläche, die Zielgruppe und die Aufgabe, die die Seite erfüllen muss. Die drei Regler (variance, motion, density) und der Stack haben absichtlich keinen Standardwert: Einen offenen Regler setzt Atelier aus der Oberfläche, und das Briefing vermerkt, dass er abgeleitet wurde.

**Die 13 Fragen von design-read**

| Frage-ID | Abschnitt | Typ | Pflicht | Standard |
| --- | --- | --- | --- | --- |
| `surface_kind` | surface | choice (12 Werte, von `landing` bis `other`) | ja | keiner |
| `audience` | audience | text | ja | keiner |
| `job` | audience | text | ja | keiner |
| `brand_assets` | assets | choice: none, partial, full | nein | keiner |
| `design_system` | assets | choice (9 Werte) | nein | `none` |
| `aesthetic_family` | direction | choice (5 Werte): minimalist, brutalist, soft-editorial, premium-dense, none | nein | `none` |
| `variance`, `motion`, `density` | direction | number von 1 bis 10 | nein | keiner (von Atelier abgeleitet) |
| `stack` | constraints | text | nein | keiner (aus dem Repository gelesen) |
| `accessibility_target` | constraints | choice: AA, AAA | nein | `AA` |
| `languages` | constraints | text | nein | `one language, LTR` |
| `required_states` | constraints | list | nein | keiner |

Hier ein echter Lauf der CLI 0.23.0 auf diesem Intake (ein Dashboard für Buchhalter, Antworten auf Französisch eingegeben). Zuerst die Gültigkeit, dann der Plan mit Exit-Code 2, dann drei Antworten, dann das Briefing.

**Design Read: check, plan, record, render**

```text
$ npx bmad-plus intake check .agents/skills/pack-design/intake.yaml
.agents/skills/pack-design/intake.yaml: valid intake design-read (design), 13 questions, 3 must-have.
$ npx bmad-plus intake plan --intake .agents/skills/pack-design/intake.yaml --answers _bmad-output/design/intake.json
design-read (design): not ready — 0 answered, 0 defaulted, 0 unknown, 13 not asked yet.
Must-haves still open: surface_kind, audience, job
Ask next (at most 6 per message):
  - surface_kind [choice] Which surface is this? A marketing landing page, a dashboard, a data table, a form, an auth or onboarding flow, a mobile screen, an email, a chat or AI surface, a checkout, a settings page, or something else? (must-have; choices: landing, dashboard, table, form, auth, onboarding, mobile, email, ai-chat, checkout, settings, other)
  - audience [text] Who uses it, and in what situation (device, time pressure, expertise, frequency)? (must-have)
  - job [text] What is the one job this page must get done, and how will you know it did? (must-have)
# In der echten Ausgabe folgen drei weitere optionale Fragen (brand_assets, design_system, aesthetic_family). Der Exit-Code ist 2: nicht bereit.
$ npx bmad-plus intake record --intake .agents/skills/pack-design/intake.yaml --answers _bmad-output/design/intake.json --set surface_kind=dashboard --set "audience=Comptables en cabinet, sur ordinateur, en fin de mois" --set "job=Repérer les factures en retard et relancer en un clic"
Recorded surface_kind, audience, job in _bmad-output/design/intake.json.
design-read (design): ready — 3 answered, 0 defaulted, 0 unknown, 10 not asked yet.
$ npx bmad-plus intake render --intake .agents/skills/pack-design/intake.yaml --answers _bmad-output/design/intake.json --out _bmad-output/design/brief.md
Brief written to _bmad-output/design/brief.md (3022 bytes); the intake is ready.
$ head -n 3 _bmad-output/design/brief.md
# Design read
<!-- owned by bmad-plus intake design-read; written by bmad-plus intake render, do not edit -->

# Die Liste „Ask next“, die record nach jedem Block ausgibt, ist hier weggelassen. Der letzte Befehl zeigt die ersten drei Zeilen des Briefings.
```

Ausgabe eines echten Laufs. Quelle: bmad-plus 0.23.0, 2026-10-19

Das zweite Protokoll setzt mit einem anderen Szenario fort (eine Landingpage für eine Kaffeebar) und zeigt die beiden anderen Status: einen mit `--default` akzeptierten Standard, einen mit `--set` gewählten Wert und einen als unbekannt markierten Regler. Beachte, dass der Plan mit einem unbekannten Regler „ready“ bleibt, weil er kein must-have ist, und dass das folgende Briefing den Status jeder Antwort zeigt.

**Design Read: Standards, unbekannt und Briefing**

```text
$ npx bmad-plus intake record --intake .agents/skills/pack-design/intake.yaml --answers _bmad-output/design/intake.json --set surface_kind=landing --set "audience=Urban professionals who buy coffee most days; on a phone, on the way to work, a few seconds of attention" --set "job=Get a first-time visitor to open a loyalty card; success is the sign-up button being tapped"
Recorded surface_kind, audience, job in _bmad-output/design/intake.json.
design-read (design): ready — 3 answered, 0 defaulted, 0 unknown, 10 not asked yet.
$ npx bmad-plus intake record --intake .agents/skills/pack-design/intake.yaml --answers _bmad-output/design/intake.json --set brand_assets=partial --default design_system --default aesthetic_family --set motion=3 --set variance=UNKNOWN
Recorded brand_assets, motion, variance, design_system, aesthetic_family in _bmad-output/design/intake.json.
design-read (design): ready — 5 answered, 2 defaulted, 1 unknown, 5 not asked yet.
Unknown: variance
$ npx bmad-plus intake render --intake .agents/skills/pack-design/intake.yaml --answers _bmad-output/design/intake.json --out _bmad-output/design/brief.md
Brief written to _bmad-output/design/brief.md (3043 bytes); the intake is ready.
# Die von record gedruckten „Ask next“-Listen sind weggelassen.
```

Ausgabe eines echten Laufs. Quelle: bmad-plus 0.23.0, 2026-10-19

**Auszug aus dem gerenderten Briefing (_bmad-output/design/brief.md)**

```md
# Design read
<!-- owned by bmad-plus intake design-read; written by bmad-plus intake render, do not edit -->

Intake `design-read` of pack `design` — 5 answered, 2 defaulted, 1 unknown, 5 not asked yet. Ready.

## Who and why

### audience (must-have)

Who uses it, and in what situation (device, time pressure, expertise, frequency)?

Answer:
    Urban professionals who buy coffee most days; on a phone, on the way to work, a few seconds of attention
Feeds: brief.md#audience

### design_system

Is a design system or component library already in use?

Answer (proposed default, not confirmed by the user):
    none
Feeds: brief.md#design-system

### variance

Layout variance, from 1 (symmetric and safe) to 10 (asymmetric and bold)? Leave it open and Atelier sets it from the surface.

Answer: unknown
Feeds: brief.md#dials

## Open questions

- variance: unknown
- density: not asked yet
- stack: not asked yet
- accessibility_target: not asked yet
- languages: not asked yet
- required_states: not asked yet
```

Atelier baut anschließend aus diesem Briefing. Die Regeln dafür stammen aus dem Design-Pack: Eine Antwort behält ihren Status in jedem Ergebnis (ein Standard oder eine Ableitung wird an der Stelle gekennzeichnet, an der sie verwendet wurde; ein unbekanntes must-have reist mit seinem Risiko), und ein offener Regler wird aus der Oberfläche gesetzt und als abgeleitet vermerkt.

<a id="example-intake-ask-first"></a>
### Ein Pack vor dem Handeln fragen lassen

Nutze es mit installiertem Design-Pack oder mit jedem Pack, das einen Intake mitbringt, vor dem ersten Ergebnis.

**In deinem KI-Assistenten**

```text
Starte den Design-Intake, bevor du irgendetwas baust. Nutze bmad-plus intake plan, um zu sehen, was offen ist, stelle mir höchstens sechs Fragen auf einmal in meiner Sprache, Pflichtfragen zuerst, schlage die Standardwerte vor, erfasse mit Risiko, was ich nicht weiß, und rendere dann das Briefing und zeige es mir, bevor du beginnst.
```

**Das solltest du erhalten** Der Assistent stellt den ersten Block (Oberfläche, Zielgruppe, Aufgabe und bis zu drei weitere), erfasst deine Antworten über `intake record`, wiederholt das, bis `plan` ready meldet, und rendert `_bmad-output/design/brief.md`. Du siehst, welche Antworten deine sind, welche vorgeschlagene Standards und welche mit ihren Risiken unbekannt, bevor die Designarbeit beginnt.

<a id="write-your-own"></a>
## Einen Intake für dein eigenes Pack schreiben

Jede Datei in deinem Projekt kann ein Intake sein: `bmad-plus intake check|plan|record|render` nehmen einfache projektrelative Pfade. Das Beispiel unten ist ein ausgedachtes Pack namens `releasekit`. Es hat zwei must-haves mit je einem Risiko, einen ehrlichen Standard (die Zielgruppe ist „both“, sofern nichts anderes gesagt wird), eine begrenzte Zahl und eine freie Liste.

**intake/release-notes.yaml**

```yaml
schema_version: 1
id: release-notes
pack: releasekit
title: Release notes brief
language: user
max_per_message: 4
sections:
  - id: release
    title: The release
    questions:
      - id: version
        ask: Which version is being released?
        kind: text
        must_have: true
        feeds: [brief.md#release]
        risk_if_unknown: The notes cannot say what changed in which version.
      - id: audience
        ask: Who reads the notes?
        kind: choice
        choices: [developers, end-users, both]
        default: both
        feeds: [brief.md#audience]
  - id: content
    title: What goes in
    questions:
      - id: breaking_changes
        ask: Is anything breaking for existing users?
        kind: boolean
        must_have: true
        risk_if_unknown: A breaking change ships without a migration note.
      - id: highlights
        ask: What are the highlights, one per item?
        kind: list
      - id: max_words
        ask: How long may the notes be?
        kind: number
        min: 50
        max: 2000
        default: 300
```

Validiere zuerst. Die Datei unten ist absichtlich kaputt (ein must-have mit Standardwert und ohne Risiko, eine Auswahl mit nur einem Wert); der Validator meldet alle drei Probleme auf einmal. Danach validiert das Terminal die einwandfreie Datei und durchläuft die Schleife damit.

**intake/broken.yaml**

```yaml
schema_version: 1
id: broken-demo
pack: releasekit
title: A deliberately broken intake
sections:
  - id: release
    title: The release
    questions:
      - id: version
        ask: Which version is being released?
        kind: text
        must_have: true
        default: "1.0.0"
      - id: audience
        ask: Who reads the notes?
        kind: choice
        choices: [everyone]
```

**Prüfen, planen, erfassen, ablehnen, rendern**

```text
$ npx bmad-plus intake check intake/broken.yaml
intake/broken.yaml: not a valid intake
  - sections[0].questions[0]: a must-have question needs "risk_if_unknown"
  - sections[0].questions[0]: a must-have question takes no "default"; the user answers it
  - sections[0].questions[1]: a choice needs at least two distinct non-empty "choices"
# Exit-Code 1.
$ npx bmad-plus intake check intake/release-notes.yaml
intake/release-notes.yaml: valid intake release-notes (releasekit), 5 questions, 2 must-have.
$ npx bmad-plus intake plan --intake intake/release-notes.yaml --answers notes/answers.json
release-notes (releasekit): not ready — 0 answered, 0 defaulted, 0 unknown, 5 not asked yet.
Must-haves still open: version, breaking_changes
Ask next (at most 4 per message):
  - version [text] Which version is being released? (must-have)
  - breaking_changes [boolean] Is anything breaking for existing users? (must-have)
  - audience [choice] Who reads the notes? (choices: developers, end-users, both; default: "both")
  - highlights [list] What are the highlights, one per item?
$ npx bmad-plus intake record --intake intake/release-notes.yaml --answers notes/answers.json --set version=UNKNOWN --set breaking_changes=yes --default audience --set "highlights=faster install, new swarm command"
Recorded version, breaking_changes, highlights, audience in notes/answers.json.
release-notes (releasekit): ready — 2 answered, 1 defaulted, 1 unknown, 1 not asked yet.
Ask next (at most 4 per message):
  - max_words [number] How long may the notes be? (default: 300)
Unknown: version — risk: The notes cannot say what changed in which version.
$ npx bmad-plus intake record --intake intake/release-notes.yaml --answers notes/answers.json --set max_words=40
Intake: max_words: value must be at least 50
$ npx bmad-plus intake record --intake intake/release-notes.yaml --answers notes/answers.json --set max_words=250
Recorded max_words in notes/answers.json.
release-notes (releasekit): ready — 3 answered, 1 defaulted, 1 unknown, 0 not asked yet.
Unknown: version — risk: The notes cannot say what changed in which version.
$ npx bmad-plus intake render --intake intake/release-notes.yaml --answers notes/answers.json --out notes/brief.md
Brief written to notes/brief.md (921 bytes); the intake is ready.
```

Ausgabe eines echten Laufs. Quelle: bmad-plus 0.23.0, 2026-10-19

**Das erzeugte Briefing (notes/brief.md)**

```md
# Release notes brief
<!-- owned by bmad-plus intake release-notes; written by bmad-plus intake render, do not edit -->

Intake `release-notes` of pack `releasekit` — 3 answered, 1 defaulted, 1 unknown, 0 not asked yet. Ready.

## The release

### version (must-have)

Which version is being released?

Answer: unknown — risk: The notes cannot say what changed in which version.
Feeds: brief.md#release

### audience

Who reads the notes?

Answer (proposed default, not confirmed by the user):
    both
Feeds: brief.md#audience

## What goes in

### breaking_changes (must-have)

Is anything breaking for existing users?

Answer:
    yes

### highlights

What are the highlights, one per item?

Answer:
    faster install
    new swarm command

### max_words

How long may the notes be?

Answer:
    250

## Open questions

- version (must-have): unknown — risk: The notes cannot say what changed in which version.
```

<a id="writing-advice"></a>
### Fragen schreiben, die ihren Platz verdienen

- Mache eine Frage nur dann zum must-have, wenn das Pack ohne sie wirklich nichts Nützliches tun kann. Der Risikosatz ist der Test: Wenn du nicht sagen kannst, was schiefgeht, ist es kein must-have.
- Gib einen Standard nur, wenn er ehrlich ist, also wenn die meisten ihn wählen würden und ein falscher Tipp wenig kostet. Ein Standard erscheint im Briefing als Vorschlag und gilt daher nie als Wort des Nutzers.
- Bevorzuge `choice` gegenüber Freitext, wenn die Antwort eine Entscheidung im Pack steuert: Der Wert ist prüfbar, das Briefing bleibt von Lauf zu Lauf vergleichbar.
- Begrenze Zahlen mit `min` und `max`: Ein abgelehnter Wert fällt bei `record` auf und nicht erst im Ergebnis.
- Halte `max_per_message` niedrig (3 bis 6). Ein langes Formular wird schlecht beantwortet und überflogen.
- Nutze `feeds`, um zu sagen, welches Artefakt jede Antwort prägt. Das kostet nichts und lässt Prüfende eine Entscheidung zu einer Frage zurückverfolgen.
- Schreibe `ask` in der einfachen Sprache, die du mit einem Kunden verwendest. Der Assistent übersetzt sie für den Nutzer, wenn `language` `user` ist; schreibe nicht mehrere Sprachen in eine Datei.

<a id="attach-to-a-pack"></a>
### Wo die Datei liegt

In einem Projekt legst du die Datei beliebig ab und übergibst sie mit `--intake`; dem Assistenten muss gesagt werden, wo sie liegt (eine Zeile in deinem Adapter oder in dem Skill, der die Arbeit steuert). Um sie Teil eines Packs im BMAD+-Quell-Repository zu machen, ergänzt du beim Pack in `registry.yaml` `intake: intake.yaml` (der Pfad ist relativ zum Pack-Verzeichnis): Der Build validiert sie dann, der Installer kopiert sie und `bmad-plus doctor` verlangt sie. Die Registry ist eine Datei des Quell-Repositorys; sie wird nicht in dein Projekt installiert. Siehe die Registry-Seite.

<a id="example-intake-write-your-own"></a>
### Einen Intake für den eigenen Workflow entwerfen und prüfen

Nutze es, wenn eine wiederkehrende Aufgabe in deinem Team immer mit denselben fehlenden Informationen beginnt.

**In deinem KI-Assistenten**

```text
Schreibe eine Intake-Datei unter intake/release-notes.yaml mit den Fragen, die wir vor Release Notes immer vergessen: die Version, ob etwas bricht, wer die Notes liest, die Highlights und eine Längengrenze. Mache nur die Version und die Frage zu Breaking Changes zu must-haves, jeweils mit dem Risiko bei Unbekanntem. Gib einen Standard nur dort, wo er ehrlich ist. Führe danach bmad-plus intake check darauf aus und behebe alle gemeldeten Probleme, bevor du mir die Datei zeigst.
```

**Das solltest du erhalten** Eine YAML-Datei, die `intake check` als gültig meldet, mit der Zahl der Fragen und must-haves in einer Zeile. Verstößt der erste Entwurf gegen eine Regel, listet der Validator alle Probleme auf einmal (zum Beispiel ein must-have mit Standardwert), und die Datei wird korrigiert, bevor du sie siehst.

<a id="safety-and-limits"></a>
## Sicherheit und Grenzen

- Antworten werden nur über `record` geschrieben, das Briefing nur über `render`. Bearbeite keines von beiden von Hand.
- `render` überschreibt ein Briefing nur, wenn die Datei mit der Besitzmarke desselben Intakes beginnt (Zeile 2). Es ersetzt nie ein Briefing, das es nicht selbst geschrieben hat. `record` überschreibt nur eine Antwortdatei desselben Intakes.
- Keiner der beiden Befehle schreibt unter `.git/`, `_bmad/`, `.bmad-plus/` oder `node_modules/` oder über einen Symlink.
- Was du eingegeben hast, wird als eingerückter Block unter `Answer:` gedruckt, sodass ein Wert nie zu einer Überschrift oder einem Listenpunkt des Briefings werden kann.
- Ändert sich die Intake-Datei, nachdem Antworten erfasst wurden, meldet `plan` die Abweichung. `record --reset` beginnt die Antwortdatei für dieselbe Intake-ID leer von vorn; eine Datei, die zu einem anderen Intake gehört, setzt es nie zurück.
- Das Pack darf seine Pipeline oder einen Schwarm nicht starten, solange ein must-have weder beantwortet noch als unbekannt markiert ist. Die Befehle prüfen das nicht selbst: Es ist eine Anweisung in den Skills von Autopilot und Nexus, die den Assistenten anweisen, zuerst den Intake jedes beteiligten Packs auszuführen, in Discovery.
- Die Laufzeit fragt nichts, erfindet nichts und ruft kein Modell auf. Ein abgelehnter Wert ändert nichts auf der Platte.

**Siehe auch**

- [Referenz: bmad-plus intake](https://bmad-plus.rochetta.fr/de/docs/reference/cli-intake/)
- [Das Design-Pack und Atelier](https://bmad-plus.rochetta.fr/de/docs/packs/design/)
- [Schwärme aus Sub-Agenten](https://bmad-plus.rochetta.fr/de/docs/concepts/swarm/)
- [Tutorial: von der Idee zum Schwarm](https://bmad-plus.rochetta.fr/de/docs/guides/idea-to-swarm/)
- [Die Registry und die Skills](https://bmad-plus.rochetta.fr/de/docs/concepts/registry-and-skills/)

[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)