Das Problem: Content-Produktion skaliert nicht
Kennst du das? 50 Landing Pages für die nächste Messe. Ein neuer Blogpost pro Woche. Produktseiten für einen Katalog mit 200 Einträgen. Jede einzelne Seite wird manuell zusammengestellt: Text schreiben, Bilder suchen, Komponenten konfigurieren, Meta-Daten pflegen. Immer derselbe Ablauf. Immer dieselben Handgriffe.
Das CMS – egal ob Storyblok, Contentful oder ein anderes Headless-System – ist dabei im Grunde ein leeres Formular. Es weiß nicht, welche Komponenten es gibt. Es weiß nicht, wie deine Marke klingt. Es weiß nicht, dass der Alt-Text fehlt oder die Heading-Hierarchie kaputt ist.
Gleichzeitig zeigt die Praxis, was Designsysteme leisten können: Konsistenz, Effizienz und Skalierbarkeit – wie wir in früheren Beiträgen beschrieben haben. Die Sparkbox-Studie belegt, dass die Verwendung eines Design Systems die Implementierung um 47 % beschleunigt. Doch was, wenn wir diesen Effizienzvorteil auch auf die Inhaltserstellung selbst übertragen könnten?
Genau das haben wir gemacht.
Die Idee: Das Design System als API-Vertrag für die KI
Unser Open-Source-Starterkit kickstartDS basiert auf einem zentralen Prinzip: Jede Komponente wird durch ein JSON Schema definiert. Dieses Schema beschreibt exakt, welche Properties eine Komponente akzeptiert, welche Typen erlaubt sind, welche Varianten existieren und wie Komponenten ineinander verschachtelt werden dürfen.
JSON Schema → TypeScript-Types
JSON Schema → Storybook-Stories
JSON Schema → CMS-Komponentenschema
JSON Schema → OpenAI-kompatible Schemas ← NEUEin Schema. Vier Outputs. Zero Drift.
Und genau hier wird es spannend: Wenn dein Design System eine maschinenlesbare, formale Beschreibung jeder verfügbaren Komponente mitbringt, dann kann eine KI diese Beschreibung nutzen, um strukturierte Inhalte zu generieren, die exakt zum Design System passen – ohne Training, ohne Fine-Tuning, ohne Prompt-Engineering-Voodoo.
Die Verbindung zwischen KI und CMS haben wir über das Model Context Protocol (MCP) realisiert – einen offenen Standard, der KI-Assistenten wie Claude oder GPT-4 mit externen Tools und Datenquellen verbindet.
Der Storyblok MCP Server: Dein CMS bekommt einen Co-Piloten
Unser Storyblok MCP Server ist ein Open-Source-Server, der dein Storyblok CMS mit KI-Assistenten verbindet. Er bietet über 25 spezialisierte Tools, die sich in fünf Kategorien gliedern:
| Kategorie | Was es tut | Beispiel-Tools |
|---|---|---|
| Content Management | Seiten lesen, erstellen, aktualisieren, löschen | list_stories, create_page_with_content, replace_section |
| KI-Content-Generierung | Inhalte strukturiert generieren und importieren | generate_content, generate_section, generate_seo |
| Analyse & Planung | Bestehende Muster erkennen, Seitenstrukturen planen | analyze_content_patterns, plan_page, list_recipes |
| Web Scraping | Externe Inhalte extrahieren und aufbereiten | scrape_url |
| Introspection | Komponenten, Assets und Icons auflisten | list_components, get_component, list_icons |
Aber die wirkliche Innovation steckt nicht in der Anzahl der Tools – sondern darin, wie sie die KI anleiten.
Das Geheimnis: Multi-Layered Hints und Schema-Injection
Die meiste „KI-generierte Content"-Erfahrung kennt man so: Du gibst einen Prompt ein, die KI antwortet mit Freitext, und du kopierst das Ergebnis irgendwohin. Das Ergebnis ist beliebig, unstrukturiert und passt selten zur vorhandenen Komponentenstruktur.
Unser Ansatz ist grundlegend anders. Wir nutzen OpenAI Structured Outputs – ein Feature, bei dem die KI nicht beliebigen Text zurückgibt, sondern ein JSON-Objekt, das einem vorgegebenen Schema entspricht. Und dieses Schema leiten wir automatisch aus dem Design System ab.
Schritt 1: Schema-Transformation (15 Passes)
Das Design System liefert Standard-JSON-Schemas. OpenAI hat aber eigene Einschränkungen: kein const-Keyword, kein format, keine optionalen Properties. Also transformieren wir das Schema in 15 automatisierten Durchläufen:
const→ Discriminator-Replacement: Dasconst-Keyword (z. B."type": { "const": "hero" }) wird durch eintype__hero-String-Feld ersetzt, das die KI als Discriminator nutzt- Unsupported Keywords entfernen:
format,minItems,$id,$schemaund andere werden gestrippt - Strict Mode erzwingen: Jedes Objekt bekommt
additionalProperties: false, alle Properties werdenrequired - Field Annotations injizieren: Properties wie
spaceBeforeodervariantbekommen kontextuelle Beschreibungen, die der KI Guidance geben
Das Ergebnis: Ein Schema, das OpenAI versteht und das exakt die Struktur deiner Design-System-Komponenten abbildet.
Schritt 2: Site-Aware Context Injection
Die KI bekommt nicht nur das Schema – sie bekommt Kontext über deine konkrete Website. Das Tool analyze_content_patterns analysiert alle veröffentlichten Stories und extrahiert:
- Komponentenfrequenz: Welche Komponenten werden tatsächlich genutzt und wie oft?
- Sektionssequenzen: Welche Komponenten folgen typischerweise aufeinander?
- Sub-Component-Counts: Wie viele Feature-Items hat eine Feature-Sektion typischerweise? (3? 4? 6?)
- Seiten-Archetypen: Welche wiederkehrenden Seitenstrukturen gibt es?
- Field Value Distributions: Welche Werte haben Felder wie
width,content_modeodervariantauf deiner Site typischerweise?
All diese Informationen fließen automatisch in den System-Prompt ein, wenn generate_section aufgerufen wird.
Schritt 3: Compositional Guidance
Hier wird es richtig clever. Das System erkennt drei Dimensionen von Kontext für jedes Feld:
- Context-free Baseline – Wie wird das Feld generell auf der Site genutzt? (z. B. „80 % aller Sections haben
width: full") - Component-Aware – Wie verhält sich das Feld, wenn eine bestimmte Komponente enthalten ist? (z. B. „Sections mit Hero haben zu 95 %
spaceBefore: none") - Position-Aware – Wie verhält sich das Feld je nach Position auf der Seite? (z. B. „Die erste Sektion hat immer
spaceBefore: none")
Diese dreischichtige Guidance wird nicht als vager Hinweis formuliert, sondern direkt in die Schema-Descriptions injiziert – sodass die KI die Information als Teil der formalen Strukturbeschreibung erhält.
Das Ergebnis: Die KI generiert keine beliebigen Inhalte. Sie generiert Inhalte, die aussehen, als hätte ein erfahrener Redakteur jede Seite manuell zusammengebaut – weil die KI dieselben Muster gelernt hat, die auch der Redakteur intuitiv anwendet.
Von der Theorie zur Praxis: Content-Operations-Workflows
Was bedeutet das alles im Alltag? Hier sind drei konkrete Workflows, die wir mit dem MCP Server und dem Workflow-Automatisierungstool n8n umgesetzt haben:
1. Bulk-Seiten-Generierung: 50 Landing Pages in 50 Minuten
Das Szenario: Eine Messe steht an. 50 Produktseiten müssen her. Jede mit Hero, Features, FAQ und CTA.
Der Workflow:
- Google Sheet mit Produktdaten (Name, Beschreibung, Features, Tonalität)
analyze_content_patterns→ Bestehende Seitenstrukturen verstehenplan_page→ KI plant die optimale Sektionsreihenfolge pro Produktgenerate_section→ Jede Sektion wird einzeln generiert, mit Kontext zur vorherigen und nächsten Sektioncreate_page_with_contentmituploadAssets: true→ Seite wird angelegt, Bilder automatisch nach Storyblok hochgeladen
Das Ergebnis: 50 Seiten. 50 Minuten. Kein Copy-Paste. Jede Seite sieht aus, als wäre sie individuell gestaltet worden – weil sie es im Grunde auch wurde, nur eben von einer KI, die das Design System versteht.
2. Content-Migration: Website-Relaunch ohne Schmerzen
Das Szenario: 120 Seiten von einem Legacy-CMS in eine neue Storyblok-Instanz migrieren.
Der Workflow:
- Sitemap der alten Website als URL-Liste
scrape_url→ Jede Seite wird als sauberes Markdown extrahiert, inklusive Bilder und Strukturgenerate_section→ Markdown dient als Prompt, die KI konvertiert in Design-System-konforme Komponentencreate_page_with_contentmituploadAssets: true→ Neue Seiten inkl. Bilder- Diff-Report für manuelle QA
Das Ergebnis: 2 Tage statt 3 Wochen. Der Redakteur reviewt und freigegeben – das Grundgerüst baut die KI.
3. Blog-Autopilot: Von RSS zu fertigem Draft
Das Szenario: Externe Branchennews automatisch in Blogpost-Entwürfe verwandeln.
Der Workflow:
- RSS-Feed als Trigger in n8n
scrape_url→ Volltext extrahierenplan_pagemitcontentType: "blog-post"→ Sektionsplangenerate_sectionpro Sektion → Inhalte generierengenerate_root_fieldfürhead,aside,cta→ Blog-Metadaten generierengenerate_seo→ SEO-optimierte Metadaten erzeugencreate_page_with_content→ Draft in Storyblok- Slack-Notification: „Neuer Entwurf wartet auf Review"
Das Ergebnis: 80 % weniger Aufwand. 100 % Kontrolle. Die KI liefert den Rohstoff, der Redakteur liefert die Qualität.
Qualitätssicherung: Nicht nur generieren, auch validieren
Ein entscheidender Aspekt, der unseren Ansatz von „einfach GPT an das CMS anklemmen" unterscheidet: Jeder generierte Inhalt wird vor dem Speichern gegen das Design-System-Schema validiert.
Die Validierung prüft automatisch:
- Unbekannte Komponententypen → Keine halluzinierten Bausteine
- Verschachtelungsverletzungen → Sub-Komponenten nur dort, wo sie hingehören
- Dual-Discriminator-Konflikte → Kein
typeundcomponentauf demselben Knoten
Zusätzlich gibt es nicht-blockierende Qualitätswarnungen für kompositorische Probleme:
- Doppelte Hero-Sektionen auf einer Seite
- Zu wenige Items in einer Feature-Liste (< 3)
- Fehlende CTAs am Seitenende
- Konkurrierende Call-to-Actions
- Redundante Headlines (Section-Headline + Komponenten-Headline mit demselben Text)
Diese Warnungen sind das digitale Äquivalent eines erfahrenen Art Directors, der über die Schulter schaut und sagt: „Das sieht nicht ganz richtig aus."
Die Architektur: Drei Ebenen, ein Ökosystem
┌─────────────────────────────────────────────────────┐
│ KI-Assistenten (Claude, GPT-4, Custom Agents) │
│ + n8n Workflows (22 native Operations) │
├─────────────────────────────────────────────────────┤
│ MCP Server / Shared Services Library │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ Schema │ │ Generate │ │ Validate │ │ Assets │ │
│ │ Prepare │ │ + Plan │ │ + Warn │ │ Upload │ │
│ └──────────┘ └──────────┘ └──────────┘ └────────┘ │
├─────────────────────────────────────────────────────┤
│ Storyblok CMS + kickstartDS Design System │
│ (JSON Schema → Komponenten → Website) │
└─────────────────────────────────────────────────────┘Die gesamte Intelligenz steckt in der mittleren Schicht – einer Shared Services Library (@kickstartds/storyblok-services), die von drei verschiedenen Runtimes konsumiert wird:
- MCP Server → Für KI-Assistenten wie Claude Desktop oder VS Code Copilot
- n8n Community Node → Für Workflow-Automatisierung ohne Code
- Next.js API Routes → Für den In-Visual-Editor „Prompter" in Storyblok
Dieselbe Schema-Vorbereitung, dieselbe Validierung, dieselbe Content-Transformation – unabhängig davon, ob ein KI-Assistent, ein n8n-Workflow oder ein Redakteur im Visual Editor den Inhalt generiert.
5 Content Types, 1 Schema Registry
Der MCP Server unterstützt nicht nur Standard-Seiten, sondern fünf verschiedene Content-Types über eine zentrale Schema Registry:
| Content Type | Architektur | Beispiel |
|---|---|---|
| page | Sektions-basiert | Landing Pages, Produktseiten |
| blog-post | Hybrid (Sektionen + Root-Felder) | Blogartikel mit Head, Aside, CTA |
| blog-overview | Hybrid | Blog-Übersichtsseiten |
| event-detail | Flat (Root-Level-Felder) | Einzelne Veranstaltungen |
| event-list | Flat | Veranstaltungsübersichten |
Jeder Content Type bringt seine eigenen Schemas, Validierungsregeln und Rezepte mit. Die KI weiß automatisch, dass ein Blogpost keinen Hero braucht (das erledigt das head-Root-Feld), aber eine Landing Page typischerweise mit einem Hero beginnt.
Section Recipes: Erprobte Muster statt Zufallstreffer
Neben der statistischen Analyse bietet der MCP Server kuratierte Section Recipes – erprobte Komponenten-Kombinationen, die nachweislich gut funktionieren:
- 19 Sektions-Rezepte (14 für Seiten, 3 für Blogposts, 2 für Events)
- 14 Seiten-Templates (Product Landing Page, About Page, FAQ Page, ...)
- 13 Anti-Patterns (Doppelte Heroes, zu wenige Stats, fehlende CTAs, ...)
Das Tool plan_page kombiniert diese Rezepte mit den Live-Patterns deiner Website und den Wünschen des Nutzers zu einem optimalen Seitenaufbau. Das Ergebnis ist nicht generisch – es ist eine Empfehlung, die auf deiner konkreten Website und deinem Design System basiert.
Der empfohlene Workflow: Section by Section
Die höchste Qualität erreichst du mit unserem empfohlenen Workflow für die sektionsweise Generierung:
analyze_content_patterns → Site-Muster verstehen
↓
plan_page → Sektionssequenz planen
↓
generate_section (×n) → Jede Sektion einzeln generieren
↓
generate_root_field (×n) → Root-Felder generieren (Blog, Events)
↓
generate_seo → SEO-Metadaten erzeugen
↓
create_page_with_content → Alles zusammensetzen und speichernJede Sektion wird mit dem Kontext der vorherigen und nächsten Sektion generiert – für saubere Übergänge. Jeder Schritt ist validiert. Und das Ergebnis sieht aus, als hätte ein Content-Stratege jede Entscheidung manuell getroffen.
Was das für dein Team bedeutet
Die Frage ist nicht „Brauchen wir KI im CMS?" Die Frage ist: „Wie lange können wir es uns leisten, ohne zu arbeiten?"
Unser Ansatz dreht die Rollen um:
| Vorher | Nachher | |
|---|---|---|
| Redakteur | Produzent (tippt, formatiert, klickt) | Kurator (prüft, verfeinert, publiziert) |
| Zeit pro Landing Page | 3 Stunden | 15 Minuten inkl. Review |
| Content-Audit | „Machen wir irgendwann mal" | Läuft jeden Montag automatisch |
| SEO-Checks | Manuelle Stichproben | Automatisch bei jeder Generierung |
| 50 Messeseiten | 3 Wochen, 1 Burnout | 50 Minuten, 0 Burnout |
Die KI ersetzt den Redakteur nicht. Sie macht ihn schneller, konsistenter und gibt ihm die Zeit zurück, die er für das Wesentliche braucht: bessere Geschichten erzählen.
Open Source und sofort einsatzbereit
Der gesamte Stack ist Open Source:
- kickstartDS – Das Design-System-Starterkit
- Storyblok MCP Server – Der MCP Server mit 25+ Tools
- n8n Community Node – 22 native n8n-Operations
- Shared Services Library – Schema, Validierung, Transformation
Du brauchst: ein Storyblok-Konto, einen OpenAI-API-Key und ein Design System auf Basis von kickstartDS. Den Rest macht der Accelerator.
Fazit: Das Design System ist der Schlüssel
Wer ein sauberes Design System hat, hat den Grundstein für AI-enabled Content Operations gelegt. Wer keins hat, automatisiert Chaos.
Das JSON Schema ist nicht nur eine Dokumentation für Entwickler – es ist der API-Vertrag zwischen Mensch, Design System und KI. Wenn die Komponentendefinition sauber ist, kann die KI sie nutzen – ohne Training, ohne Fine-Tuning. Einfach: saubere Schemas rein → sauberer Content raus.
Das ist kein KI-Trick. Das ist die Dividende von gutem Software-Engineering.
Du willst sehen, wie das funktioniert? Wir zeigen es dir gerne in einer Live-Demo.
Sprich uns an · GitHub Repository · kickstartDS Website
Dieser Beitrag ist Teil unserer Serie zu AI-enabled Content Operations. Folge uns auf LinkedIn für wöchentliche Insights zu Design Systems, MCP und Content-Automatisierung.
#AIenabledCMS #ContentOperations #kickstartDS #MCP #DesignSystem
