# Design-Pack: Atelier fragt zuerst, baut dann, prüft und gestaltet neu > Atelier, Design-Engine von BMAD+: Intake mit 13 Fragen, dann Bauen, Prüfen oder Neugestalten über drei Skills, gekennzeichnete Belege, zitiertes Pre-flight-Urteil. Installation, echte Sitzung. Canonical: https://bmad-plus.rochetta.fr/de/docs/packs/design/ 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/) › Design-Pack: Atelier fragt zuerst, baut dann, prüft und gestaltet neu Das Design-Pack installiert Atelier, den BMAD+-Agenten für Oberflächen: Marketingseiten, Dashboards, Datentabellen, Formulare, Anmelde- und Erststart-Abläufe, mobile Ansichten und E-Mails. Atelier beginnt nicht mit dem Zeichnen. Zuerst führt er einen Intake durch, eine kurze Fragenliste dazu, wofür der Bildschirm da ist und wer ihn nutzt, und schreibt die Antworten in ein Briefing, das zum Vertrag für alles Weitere wird. Dann plant, baut, prüft oder überarbeitet er die Oberfläche, indem er drei Skills mit den eigentlichen Designregeln öffnet, und schließt mit dem Urteil einer Auslieferungs-Checkliste, dem Pre-flight. Video: [Atelier, das Design-Pack](https://bmad-plus.rochetta.fr/media/atelier-design-en.mp4) — Der Design-Read, Tokens und Zustände und ein Pre-flight-Urteil aus der Checkliste. [Untertitel (WebVTT)](https://bmad-plus.rochetta.fr/media/atelier-design-de.vtt) Transkript: > Atelier, das zehnte Pack, baut, prüft und überarbeitet Oberflächen nach nachprüfbaren Regeln. Es beginnt mit einem Design-Read: Fragen zur Oberfläche, zur Zielgruppe und zur einen Aufgabe, die die Seite erfüllen muss. Ein Regler, den du offen lässt, wird aus der Oberfläche abgeleitet, und das Briefing vermerkt, dass er abgeleitet wurde. Danach baut es mit semantischen Tokens, WCAG-AA-Kontrast und allen abgedeckten Zuständen. Am Ende steht ein Pre-flight. „Bereit“ oder „nicht bereit“ wird an der Checkliste abgelesen, nicht daran, wie der Bildschirm aussieht. Der Installer kopiert seine drei Skills, und doctor prüft sie. Transkript mit Bildbeschreibung: - **0:00** Im Bild: Durchscheinende Glasplatten treiben auseinander durch einen dunkelblauen Raum und schieben sich dann zu einem ordentlichen Stapel zusammen, der in warmem Licht leuchtet. Die Einblendung lautet auf Englisch „Atelier · Design pack“. Sprechtext: Atelier, das zehnte Pack, baut, prüft und überarbeitet Oberflächen nach nachprüfbaren Regeln. - **0:08** 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…“ und, orange umrahmt, „Must-haves still open: surface_kind, audience, job“. Es folgt eine Liste von Fragen, jeweils mit Typ und „(must-have)“, wo es zutrifft. Dann wird der Befehl 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. Er gibt „Recorded surface_kind, audience, job, design_system in _bmad-output/design/intake.json.“ und „design-read (design): ready — 2 answered, 1 defaulted, 1 unknown, 9 not asked yet.“ aus. Die noch offenen Fragen scrollen vorbei, darunter die drei Regler; „[number] Layout variance“ ist umrahmt, dann folgen motion, density und stack. Der Bildschirm endet mit umrahmtem „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: Es beginnt mit einem Design-Read: Fragen zur Oberfläche, zur Zielgruppe und zur einen Aufgabe, die die Seite erfüllen muss. Ein Regler, den du offen lässt, wird aus der Oberfläche abgeleitet, und das Briefing vermerkt, dass er abgeleitet wurde. - **0:24** Im Bild: Kleine Glaskacheln erscheinen eine nach der anderen und füllen ein Raster, Reihe für Reihe, bis ein Block aus acht Spalten und vier Reihen vollständig ist. Einige der Kacheln leuchten bernsteinfarben. Die Einblendung lautet auf Englisch „Tokens · WCAG AA · every state“. Sprechtext: Danach baut es mit semantischen Tokens, WCAG-AA-Kontrast und allen abgedeckten Zuständen. - **0:32** Im Bild: Eine dünne waagerechte Linie warmen Lichts liegt auf einem dunklen Horizont. Ein weicher Lichtstrahl fächert sich darüber auf und spiegelt sich im dunklen Wasser darunter. Die englische Einblendung „Pre-flight“ blendet ein. Sprechtext: Am Ende steht ein Pre-flight. - **0:35** Im Bild: Ein Terminal. Es wird der Befehl sed -n '7,28p' .agents/skills/design/references/80-preflight.md getippt. Die Datei erscheint langsam als Checkliste, jeder Punkt beginnt mit einem leeren Kästchen „[ ]“. Abschnitt „A. Foundations“ behandelt semantische OKLCH-Farb-Tokens, Kontrast, höchstens zwei Schriftfamilien, die 4-px-Abstandsskala und Radien. Abschnitt „B. Accessibility (blockers — any fail blocks delivery)“ listet semantisches HTML, Bedienbarkeit per Tastatur, beschriftete Eingabefelder, Zielgröße, Reflow bei 320 px, reduzierte Bewegung, Überschriften und Landmarken sowie einen Fokus, der nicht von fixierten Elementen verdeckt wird. Abschnitt „C. States (the most-forgotten section)“ beginnt mit „Empty (first-run) designed with a CTA“. Der gesamte Terminaltext ist englisch. Sprechtext: „Bereit“ oder „nicht bereit“ wird an der Checkliste abgelesen, nicht daran, wie der Bildschirm aussieht. - **0:45** Im Bild: Ein Terminal. Es wird der Befehl bmad-plus doctor getippt. Der Bildschirm zeigt „BMAD+ Doctor v0.23.0“ und „Manifest found: v0.23.0“, dann einen „BMAD+ Health Report“, dessen erste Zeile, „87/87 checks passed“, orange umrahmt ist. Darunter: „0 error(s), 0 warning(s)“, „Installed: v0.23.0 | Executing CLI: v0.23.0“ und „Ownership inventory: complete“. Der Bildschirm endet mit einem Hinweis, dass die veröffentlichte Version hier nicht geprüft wird (der Befehl bmad-plus update-check --json fragt npm ab), und „Installation checks passed.“ in Grün. Der gesamte Terminaltext ist englisch. Sprechtext: Der Installer kopiert seine drei Skills, und doctor prüft sie. ## Wann du es brauchst - Du baust einen neuen Bildschirm und willst ein Ergebnis, das zur Zielgruppe passt und leere, ladende und fehlerhafte Zustände abdeckt, keine generische Vorlage. - Du brauchst ein Design-Token-Blatt (Farben, Schrift, Abstände) für deinen Stack oder ein Barrierefreiheits-Audit des Bestehenden. - Ein Live-Produkt mit Nutzern, Marke und indexierten Adressen soll sein Aussehen ändern, ohne zu verlieren, was funktioniert. ## Was installiert wird Zwei Dinge landen in deinem Projekt. Das Pack selbst in `.agents/skills/pack-design/`: der Dispatcher `SKILL.md` (Skill `design-engine`), die Persona `design-engine.md`, der Intake `intake.yaml` und ein Manifest. Und die Regeln, vom Installer aus dem npm-Paket `design-skill` kopiert, exakt auf Version 0.2.1 festgelegt, in drei Skill-Ordner neben dem Pack. BMAD+ kopiert nur das Verzeichnis `skills/` dieses Pakets; das Paket enthält außerdem einen Verknüpfungsbefehl, den BMAD+ nie ausführt. **Die drei Design-Skills (design-skill 0.2.1)** | Skill | Installiert in | Zuständig für | | --- | --- | --- | | `design` | `.agents/skills/design/` | Was ein neuer Bildschirm erfüllen muss, die Referenzmodule je Oberfläche, Token-Blätter und die Auslieferungs-Checkliste (Pre-flight), mit der er schließt | | `design-review` | `.agents/skills/design-review/` | Das Prüfprotokoll und seine Schweregrad-Skala | | `redesign` | `.agents/skills/redesign/` | Wie ein Live-Produkt geändert wird, ohne zu verlieren, was funktioniert: Audit, Entscheidung, Migrationsplan, Bau, Verifikation | Dieses Pack besitzt selbst keine Designregel. Fehlt `.agents/skills/design/SKILL.md` (das Paket wurde nicht aufgelöst oder das Kopieren brach ab), meldet Atelier das, verweist auf `bmad-plus doctor`, das die fehlenden Dateien nennt, und hält an, statt Regeln zu improvisieren. Der Installer listet vor dem Schreiben jede Datei jedes gewählten Packs auf; ein fehlendes `design-skill` in der richtigen Version bricht die Installation also ab, ohne dein Projekt zu berühren. ### Befehle und Rollen **Der /design-Router** | Befehl | Rolle | Was er tut | | --- | --- | --- | | `/design read` | Builder | Startet oder setzt den Intake fort, legt die Regler und den Stack fest, schreibt `_bmad-output/design/brief.md`, gibt einen einzeiligen Design-Read (Oberfläche, Zielgruppe, ästhetische Familie) und die drei Regler mit Herkunft aus, gesetzt oder abgeleitet | | `/design build ` | Builder | Öffnet bei fertigem Briefing `design`, baut die Oberfläche und liefert mit zitiertem Checklisten-Urteil | | `/design review ` | Reviewer | Öffnet `design-review`, prüft die Dateien oder Seite und schreibt `_bmad-output/design/review.md`, jeder Befund als `tool` oder `inspection` gekennzeichnet | | `/design redesign` | Redesigner | Öffnet `redesign` und folgt ihm bis zum Ende: Audit, begründete Entscheidung, Migrationsplan mit Such- und Barrierefreiheitsrisiken, Bau, Verifikation gegen die alte Version | | `/design tokens` | Builder | Erzeugt das Token-Blatt für den im Briefing festgehaltenen Stack | | `/design` oder `/design help` | - | Zeigt diese Tabelle und den Stand des Intakes | Die drei Rollen wechseln automatisch, wenn die Anfrage passt. Stichwörter wie Atelier, /design, design tokens, maquette, wireframe, landing page, make it look good, Barrierefreiheit, refonte oder redesign wecken den Agenten. Atelier kündigt den Wechsel an, und du kannst mit skip im aktuellen Modus bleiben. ## Der Intake: 13 Fragen, 3 Pflichtangaben Der Design-Read ist ein Pack-Intake: eine validierte Fragenliste in `intake.yaml`, in kleinen Gruppen (höchstens sechs pro Nachricht) und in deiner Sprache gestellt, Pflichtangaben zuerst. Sie hat 13 Fragen in fünf Abschnitten (Oberfläche, Zielgruppe, Bestand, Richtung, Rahmenbedingungen). Drei sind Pflicht, ohne die der Intake nicht bereit sein kann: `surface_kind`, `audience` und `job`. Jede Antwort behält in allen Ergebnissen einen von drei Status: `answered` (du hast es gesagt), `defaulted` (ein vorgeschlagener Standard blieb) oder `unknown` (du wusstest es nicht, mit seinem Risiko festgehalten). Davon getrennt kennzeichnen die Ergebnisse von Atelier etwas als inferred, wenn Atelier es selbst aus Produkt oder Repository liest, etwa einen offen gelassenen Regler oder den Stack. Das ist die eigene Konvention der Persona, kein vierter Status des Intakes, und eine Ableitung wird nie als deine Antwort festgehalten. **Die 13 Fragen des Design-Reads** | Frage-ID | Abschnitt | Art | Pflicht | Standard | Fragt nach | | --- | --- | --- | --- | --- | --- | | `surface_kind` | `surface` | choice | ja | - | Welche Art von Oberfläche: landing, dashboard, table, form, auth, onboarding, mobile, email, ai-chat, checkout, settings oder other | | `audience` | `audience` | text | ja | - | Wer es nutzt und in welcher Situation (Gerät, Zeitdruck, Erfahrung, Häufigkeit) | | `job` | `audience` | text | ja | - | Die eine Aufgabe, die die Seite erfüllen muss, und woran du merkst, dass sie es tat | | `brand_assets` | `assets` | choice | nein | - | Vorhandene Markenelemente: keine, teilweise oder vollständig | | `design_system` | `assets` | choice | nein | none | Verwendetes Designsystem oder Komponentenbibliothek (shadcn, radix, mantine, material, fluent, carbon, polaris, other) | | `aesthetic_family` | `direction` | choice | nein | none | Ästhetische Familie: minimalist, brutalist, soft-editorial, premium-dense oder none | | `variance` | `direction` | number 1-10 | nein | - | Layout-Varianz, von symmetrisch und sicher bis asymmetrisch und kühn | | `motion` | `direction` | number 1-10 | nein | - | Bewegung, von statisch bis choreografiert | | `density` | `direction` | number 1-10 | nein | - | Dichte, von luftig wie eine Galerie bis vollgepackt wie ein Cockpit | | `stack` | `constraints` | text | nein | - | Stack, der es rendert; bleibt es offen, liest Atelier ihn aus dem Repository | | `accessibility_target` | `constraints` | choice | nein | AA | WCAG-Konformitätsstufe: AA oder AAA | | `languages` | `constraints` | text | nein | one language, LTR | Zu bedienende Sprachen und ob eine Rechts-nach-links-Schrift dabei ist | | `required_states` | `constraints` | list | nein | - | Zustände jenseits des Idealfalls: leer, Laden, Fehler, keine Ergebnisse, offline, Teilberechtigung | Die drei Regler (`variance`, `motion`, `density`, je 1 bis 10) haben bewusst keinen Standard. Einen offenen Regler setzt der Skill `design` anhand von Oberfläche und Briefing, und das Briefing sagt, dass er abgeleitet wurde. Eine Pflichtangabe, die du nicht beantworten kannst, wird als `UNKNOWN` samt Risiko festgehalten, und dieses Risiko wandert in den Einleitungsabsatz von allem, was darauf aufbaut. ### Beleg-Kennzeichnung und Pre-flight-Urteil - Jeder Befund ist `tool`, wenn in dieser Sitzung ein Befehl lief und der Bericht ihn nennt und seine Ausgabe zitiert, oder `inspection`, wenn Atelier die Dateien gegen die Checkliste las. Eine Zahl steht nur unter `tool`. Eine vom Skill erwartete Prüfung, die nicht laufen konnte, steht unter „not run“, nie geschätzt. - Der Skill `design` schließt mit einer Auslieferungs-Checkliste (dem Pre-flight, in seinem Referenzmodul `references/80-preflight.md`). Jedes Ergebnis endet mit den Punkten dieser Liste und ihrem Stand, und „bereit“ oder „nicht bereit“ kommt von ihr, nicht vom Aussehen des Bildschirms. - Der Umfang folgt der Anfrage: Ein Bau berührt die genannten oder vom Briefing implizierten Dateien, ein Review ändert nichts, ein Redesign beginnt mit seinem Audit. Ein Paket installieren, einen Browser öffnen oder einen Scanner starten wird namentlich vorgeschlagen und wartet auf dein Ja. ### Übergaben an andere Agenten **Was Atelier übergibt und an wen** | An | Wann | Was übergeben wird | | --- | --- | --- | | Sentinel | Nach einem Bau oder Redesign | Die Zustandsmatrix und Tastaturwege zum Testen; solange dieses Pack installiert ist, gibt Sentinels UX-Review visuelles Design und Barrierefreiheit an Atelier ab | | SEO-Pack (Scout, Chief) | Vor dem Launch und vor einem Redesign, das Adressen, Überschriften oder strukturierte Daten ändert | Der Migrationsplan mit den Suchrisiken, die der Skill `redesign` markiert hat | | Shield | Einwilligungs- und Datenschutzoberflächen: Cookie-Banner, Datenanfragen, Aufbewahrungshinweise | Die nach dem Einwilligungsmodul gebaute Oberfläche; Shield verantwortet Rechtsgrundlage und Verzeichnisse | | Dev Studio (Rachel, Oholiab) | Abläufe und Wireframes liegen vor der visuellen Ebene vor, oder die Umsetzung gehört in einen Sprint | Rachels Abläufe speisen den Intake; entweder Rachel oder Atelier betreut einen Bildschirm, und die Übergabe sagt, wer | | Nexus | Der Autopilot oder eine Pipeline erreicht einen Design-Schritt | Nexus führt den Intake dieses Packs über Atelier vor dem Schritt aus und geht nie über eine offene Pflichtangabe hinweg | ## Schnellstart 1. **Das Pack installieren** Core wird automatisch ergänzt. Die Abhängigkeit `design-skill` kommt mit dem BMAD+-Paket; der Installer kopiert ihre drei Skills und listet vor dem Schreiben jede Datei auf. ```sh npx bmad-plus install --packs design ``` 2. **Die Installation prüfen** Die Diagnose prüft die Pack-Dateien, auch die drei kopierten Skills. ```sh npx bmad-plus doctor ``` 3. **Mit dem Design-Read beginnen** Atelier stellt zuerst seine Fragen, in kleinen Gruppen, und schreibt dann das Briefing. ```sh /design read ``` 4. **Bauen, prüfen oder neu gestalten** Stütze dich auf das Briefing für eine neue Oberfläche oder zeige Atelier das Bestehende. ```sh /design build dashboard ``` ## Eine echte Sitzung, aufgezeichnet Diese Mitschriften wurden beim Ausführen der CLI 0.23.0 in einem Wegwerf-Projekt aufgezeichnet. Der Installer lief auf Französisch; die Intake-Befehle geben Englisch aus. Hier unwichtige Zeilen sind weggelassen. **Die Packs Core und Design installieren** ```text $ npx bmad-plus install --yes --lang fr --packs core,design --tools claude-code --directory ./demo-app * Packs sélectionnés: ⚙️ Core, 🎨 Design o ✅ 5 agents, 9 skills, 4 fichiers copiés — BMAD+ est prêt ! Parle à Atlas pour commencer 🚀 $ npx bmad-plus doctor --directory ./demo-app 87/87 checks passed 0 error(s), 0 warning(s) ``` Ausgabe eines echten Laufs. Quelle: bmad-plus 0.23.0, 2026-10-19 **Den Intake validieren und sehen, was offen ist** ```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) # Der Plan endet mit Code 2, solange eine Pflichtangabe offen ist. Die Liste setzt sich mit brand_assets, design_system und aesthetic_family fort. ``` Ausgabe eines echten Laufs. Quelle: bmad-plus 0.23.0, 2026-10-19 **Die drei Pflichtangaben festhalten, dann das Briefing erzeugen** ```text $ 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. # Die erste Zeile des Briefings lautet „# Design read“; die zweite ist ein Marker, der besagt, dass es bmad-plus intake gehört und nicht von Hand geändert werden soll. ``` Ausgabe eines echten Laufs. Quelle: bmad-plus 0.23.0, 2026-10-19 ## Beispiele zum Kopieren ### Design-Read, Bau, dann das Pre-flight-Urteil Der komplette Ablauf an einem Bildschirm. Atelier fragt zuerst, sei also bereit zu antworten. **In deinem KI-Assistenten** ```text Atelier, mach den Design-Read für die Rechnungsliste meiner App, baue den Bildschirm und schließe mit dem Pre-flight-Urteil. ``` **Das solltest du erhalten** Der Design-Read wird festgehalten (`_bmad-output/design/intake.json` und `brief.md`), der Bildschirm wird mit den im Briefing genannten Zuständen gebaut, und die Antwort endet mit der Auslieferungs-Checkliste, jeder Punkt mit seinem Stand, und dem daraus folgenden Urteil bereit oder nicht bereit. ### Nur der Design-Read Nutze es, um das Briefing mit einem Kunden oder Team festzulegen, bevor jemand zeichnet oder programmiert. **In deinem KI-Assistenten** ```text Atelier, mach mit mir den Design-Read für das Erststart-Onboarding unseres Planungswerkzeugs. Zu Dichte und Bewegung habe ich noch keine Meinung, lass sie offen und setze sie anhand der Oberfläche. ``` **Das solltest du erhalten** Atelier startet oder setzt den Intake mit dem Skill `bmad-plus-intake` fort, höchstens sechs Fragen pro Nachricht und Pflichtangaben zuerst, hält Antworten mit `bmad-plus intake record` fest, hält an, wenn `bmad-plus intake plan` bereit sagt, erzeugt `_bmad-output/design/brief.md` und gibt eine Zeile (Oberfläche, Zielgruppe, ästhetische Familie) mit den drei Reglern aus, jeweils von dir gesetzt oder abgeleitet; die von dir offen gelassenen kommen als inferred markiert zurück. ### Eine Oberfläche aus dem Briefing bauen Starte es, sobald das Briefing existiert. Oberflächen sind landing, dashboard, table, form, auth, onboarding, mobile, email, ai-chat, checkout und settings. **In deinem KI-Assistenten** ```text /design build dashboard ``` **Das solltest du erhalten** Atelier öffnet den Skill `design`, folgt seinem Routing für ein Dashboard und baut im Stack, den das Briefing festhält (aus dem Repository gelesen, falls du ihn offen ließest). Offene Pflichtfragen wandern mit ihrem Risiko in den Einleitungsabsatz des Ergebnisses, und die Lieferung endet mit dem zitierten Checklisten-Urteil. ### Ein Token-Blatt erzeugen oder vereinheitlichen Nützlich, wenn Farbwerte direkt in Komponenten stehen, was auch die Builder-Rolle auslöst. Ist der Intake noch nicht bereit, führt Atelier ihn zuerst aus. **In deinem KI-Assistenten** ```text /design tokens ``` **Das solltest du erhalten** Atelier öffnet `design` und seine Token-Module und erzeugt das Token-Blatt für den Stack im Briefing, sodass Komponenten Farben, Schrift und Abstände aus Tokens statt aus Rohwerten beziehen. Das Blatt landet unter `_bmad-output/design/`. ### Eine bestehende Seite prüfen, mit gekennzeichneten Belegen Ein Review ändert nichts; es schreibt nur den Bericht. Gib einen Ordner, eine Datei oder eine URL an. **In deinem KI-Assistenten** ```text /design review src/pages/pricing ``` **Das solltest du erhalten** Das Protokoll des Skills `design-review` läuft, und `_bmad-output/design/review.md` listet Befunde, geordnet danach, was die Lieferung blockiert, dann was verwirrt, dann was poliert. Jeder Befund ist `tool` (ein Befehl lief und seine Ausgabe wird zitiert) oder `inspection` (gegen die Checkliste gelesen). Nicht ausführbare Prüfungen stehen unter „not run“. ### Eine Live-Website neu gestalten, ohne ihren Such-Traffic zu verlieren Wörter wie refonte, redesign, refresh, modernize oder rebrand schalten Atelier in die Redesigner-Rolle. **In deinem KI-Assistenten** ```text /design redesign die Marketing-Website https://example.com. Behalte das Logo und diese indexierten URLs: /pricing, /features und /blog. Sag mir, welche Änderungen Suche oder Barrierefreiheit gefährden. ``` **Das solltest du erhalten** Der Skill `redesign` wird von Anfang bis Ende befolgt: zuerst ein Audit, eine Entscheidung bewahren oder überarbeiten mit Begründung, ein Migrationsplan, der Such- und Barrierefreiheitsrisiken für die genannten URLs markiert, der Bau über `design` und eine Verifikation gegen die alte Version. Atelier kann aus dem Prompt nicht wissen, welche URLs ranken, deshalb nennst du sie. Ein Browser-, Scanner- oder Crawl-Schritt wird namentlich vorgeschlagen und läuft erst nach deinem Ja. Der Migrationsplan geht an das SEO-Pack, bevor eine Änderung an Adressen, Überschriften oder strukturierten Daten live geht. ### Sagen, was du nicht weißt Eine unbekannte Pflichtangabe ist erlaubt. Sie wird mit ihrem Risiko festgehalten, statt erfunden zu werden. **In deinem KI-Assistenten** ```text Atelier, entwirf einen Einstellungsbildschirm für unsere Admin-Konsole. Ich weiß noch nicht, wer der typische Admin ist; halte das als unbekannt fest und trage das Risiko mit. ``` **Das solltest du erhalten** `audience` wird als `UNKNOWN` mit dem eigenen Risikotext des Intakes (auf Englisch) festgehalten: „Density, tone and the size of touch targets are guessed instead of chosen; the page serves nobody in particular.“, also Dichte, Ton und Größe der Touch-Ziele werden geraten statt gewählt, und die Seite dient niemandem im Besonderen. Das Briefing markiert es als offen, und der gelieferte Bildschirm sagt im Einleitungsabsatz, dass er auf dieser Unbekannten beruht. Atelier fragt vor dem Bau weiter nach Oberfläche und Aufgabe: Der Intake ist erst bereit, wenn alle drei Pflichtangaben beantwortet oder als unbekannt markiert sind. ### Den fertigen Bildschirm an Sentinel übergeben Nach einem Bau sind Zustandsmatrix und Tastaturwege das, was ein Tester braucht. **In deinem KI-Assistenten** ```text Atelier, die Rechnungsliste ist gebaut. Bereite die Übergabe an Sentinel vor: die Zustandsmatrix und die zu testenden Tastaturwege. Danach Sentinel, schreibe das passende Abnahmeprotokoll. ``` **Das solltest du erhalten** Atelier listet jeden entworfenen Zustand und jeden Tastaturweg als Übergabe auf. Sentinels Recette-Rolle macht daraus Schritte eines Abnahmeprotokolls; solange das Design-Pack installiert ist, überlässt Sentinel das Urteil zu visuellem Design und Barrierefreiheit Atelier. ## Was es schreibt und wo **Unter _bmad-output/design/ geschriebene Dateien** | Datei | Geschrieben von | Inhalt | | --- | --- | --- | | `intake.json` | `bmad-plus intake record` | Die Antworten mit ihrem Status: answered, defaulted, unknown | | `brief.md` | `bmad-plus intake render` | Der Design-Read; Zeile 2 trägt einen Eigentumsmarker, und die Datei wird nie von Hand geändert | | `review.md` | `/design review` | Befunde mit den Kennzeichen tool oder inspection | | Token-Blatt | `/design tokens` | Tokens für den Stack im Briefing | Der Code selbst wird dort in die Quellen deines Projekts geschrieben, wo du es verlangt hast. Die Ausgabe überschreibt nie ein Briefing, das sie nicht geschrieben hat, und der Intake weigert sich, unter `.git/`, `_bmad/`, `.bmad-plus/` oder `node_modules/` zu schreiben. ## Datenflüsse und Voraussetzungen - Nur Node.js 20. Das npm-Paket `design-skill`, auf 0.2.1 festgelegt, wird von der normalen BMAD+-Installation geholt (es ist eine seiner sieben Laufzeit-Abhängigkeiten); der Installer kopiert daraus die Skills. - Das Pack führt kein Skript aus, startet keinen eigenen Prozess und sendet nirgendwohin etwas. Eine Prüfung, die einen Browser oder Scanner braucht, läuft nur über die Werkzeuge deines eigenen Projekts, namentlich vorgeschlagen und mit deiner Zustimmung. Die Datenflüsse des Host-Werkzeugs nach außen gelten wie bei jedem Agenten. ## Grenzen und Stolpersteine > **Warnung · Ohne Skills kein Design** Atelier hängt vollständig von den drei kopierten Skills ab. Ohne sie hält er an, statt Regeln aus dem Gedächtnis zu zitieren. Nach einer unterbrochenen Installation oder manuellem Löschen führe `bmad-plus doctor` aus und installiere neu. > **Hinweis · Eine Zahl braucht ein Werkzeug** Kontrastverhältnisse, Performance-Werte oder Befundzahlen erscheinen nur, wenn in der Sitzung ein Befehl lief. Sonst ist der Befund eine Inspektion ohne Zahl, und die Prüfung steht als nicht ausgeführt. Lies eine Inspektion nicht als Messung. > **Tipp · Wer den Bildschirm betreut** Atelier überschneidet sich mit Sentinels UX-Review und mit Rachel in Dev Studio. Ist das Design-Pack installiert, bestimmen seine Regeln visuelles Design und Barrierefreiheit, und die anderen geben diese ab. Wähle für einen Bildschirm einen Verantwortlichen und lass die Übergabe sagen, wer es ist. **Siehe auch** - [Alle zehn Packs im Vergleich](https://bmad-plus.rochetta.fr/de/docs/packs/packs-overview/) - [Referenz des Befehls intake](https://bmad-plus.rochetta.fr/de/docs/reference/cli-intake/) - [Intake, wie es funktioniert](https://bmad-plus.rochetta.fr/de/docs/concepts/intake/) - [SEO-/GEO-Pack](https://bmad-plus.rochetta.fr/de/docs/packs/seo/) - [Dev-Studio-Pack (Rachel)](https://bmad-plus.rochetta.fr/de/docs/packs/dev-studio/) - [Referenz des Befehls doctor](https://bmad-plus.rochetta.fr/de/docs/reference/cli-doctor/) [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)