Contentkit ist für Maschinen gebaut

Diesen Beitrag anhören (13 Min.)

Ein Content-Management-System ohne Verwaltungsoberfläche klingt zunächst wie ein unvollständiges Produkt. Bei Contentkit ist diese Lücke die entscheidende Eigenschaft. Es gibt keinen Seiteneditor, keinen Page Builder und kein Plugin-Verzeichnis. Stattdessen gibt es Markdown, eine HTTP-API und einen Veröffentlichungsprozess, der aus geprüften Eingaben einen unveränderlichen Stand erzeugt. Genau diese Form passt zu einer Arbeitswelt, in der Claude Code, Codex, Build-Pipelines und eigene Fachagenten Inhalte erzeugen oder aktualisieren.

Teil 1 der Serie „Contentkit – Publishing für Maschinen“.

Der Verzicht auf eine Verwaltungsoberfläche bedeutet nicht, dass die fertige Website ohne gute Bedienung auskommen muss. Leser bekommen Navigation, Suche, RSS, zugängliche Seiten, Dokumentationshierarchien, geschützte Bereiche und auf Wunsch vorgelesene Artikel. Ohne Oberfläche bleibt der Steuerungsbereich. Dort reden Maschinen miteinander: Ein Agent liefert Markdown, ein Dienst prüft es, Contentkit baut eine Vorschau oder einen Release, ein Webhook meldet das Ergebnis an den nächsten Prozess.

Diese Trennung ist wichtiger, als sie auf den ersten Blick wirkt. Ein klassisches CMS verbindet Autorenoberfläche, Inhaltsmodell, Renderer, Erweiterungen und Betrieb in einem Produkt. Für Menschen ist das bequem. Für Agenten entsteht daraus häufig ein Hindernislauf durch Formulare, nicht dokumentierte Zustände und Erweiterungen mit eigener Logik. Contentkit setzt an dieser Stelle einen kleineren, strengeren Vertrag.

Der Vertrag besteht aus Text und HTTP

Die Eingabe ist eine Markdown-Datei mit YAML-Frontmatter. Sie lässt sich in Git versionieren, im Code-Review lesen, mit Standardwerkzeugen vergleichen und von praktisch jedem Agenten bearbeiten. Der Transport läuft über eine dokumentierte HTTP-API. Die Ausgabe ist ein vollständiger statischer Website-Stand.

flowchart LR
    Q["Quellsystem<br/>oder Repository"] --> A["Agent<br/>erzeugt Markdown"]
    A --> V["Contentkit API<br/>prüft den Vertrag"]
    V --> P["Vorschau<br/>unveränderlicher Stand"]
    P --> R["Atomarer Release<br/>statische Website"]
    R --> H["Menschen<br/>lesen und suchen"]
    R --> M["Maschinen<br/>lesen JSON und Markdown"]

Ein Agent muss also nicht lernen, wo ein Redakteur in einer Oberfläche klicken würde. Er muss nur eine Datei erzeugen und einen stabilen Endpunkt aufrufen. Ein stark vereinfachter Upload sieht so aus:

curl -X POST "$CONTENTKIT_URL/v1/sites/$SITE/content" \
  -H "Authorization: Bearer $CONTENTKIT_PUBLISH_API_KEY" \
  -F "document=@release-notes.de.md;type=text/markdown"

Die Antwort enthält die neue Revision. Sie ist noch nicht automatisch öffentlich. Ein zweiter Aufruf baut daraus einen Release:

curl -X POST "$CONTENTKIT_URL/v1/sites/$SITE/releases" \
  -H "Authorization: Bearer $CONTENTKIT_PUBLISH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "revision_ids": ["7f2d8c0a-4d71-4cc2-a032-9b0eb632650d"],
    "reason": "document the 2.4 API release"
  }'

Zwischen diesen beiden Aufrufen kann eine Vorschau stehen. Das ist kein Sonderweg für Menschen, sondern derselbe technische Prozess mit einem vorläufigen, ablaufenden Zugriff. Ein automatischer Prüfer kann die erzeugten Seiten abrufen, Überschriften zählen, Links testen oder sicherstellen, dass eine geschützte Anleitung nicht im öffentlichen Suchindex auftaucht.

Kein Klickweg, den ein Agent nachspielen muss

Browser-Automatisierung ist sinnvoll, wenn nur eine Oberfläche vorhanden ist. Für einen zuverlässigen Veröffentlichungsweg bleibt sie dennoch ein Notbehelf. Schaltflächen ändern ihre Beschriftung, Dialoge erscheinen abhängig vom Zustand, Sitzungen laufen ab. Selbst wenn ein Agent die Oberfläche bedienen kann, ist schwer zu erkennen, welche fachliche Operation hinter einer Klickfolge steckt.

Eine API macht die Absicht sichtbar. POST /content erzeugt eine Revision. POST /previews baut eine Vorschau. POST /releases veröffentlicht einen neuen Stand. Das lässt sich protokollieren und testen. Fehler haben Statuscodes und strukturierte Antworten. Ein unbekanntes Frontmatter-Feld oder eine fehlerhafte Dokumentationshierarchie kann mit 422 abgelehnt werden, bevor irgendetwas öffentlich wird.

Für den Alltag entstehen daraus drei konkrete Vorteile:

Agenten verwenden dieselben Werkzeuge wie bei Quellcode: Dateien, Diffs, Tests und HTTP-Aufrufe.
Automatisierung muss keine verborgenen Sitzungszustände oder Klickfolgen nachbilden.
Jede Wirkung lässt sich auf eine Revision, einen Release und den auslösenden Schlüssel zurückführen.

Der letzte Punkt wird mit KI-Agenten besonders wertvoll. Ein Modell kann sehr schnell viel brauchbaren Text erzeugen. Es kann ebenso schnell einen falschen Produktnamen, eine veraltete Versionsnummer oder eine erfundene Option verteilen. Schnelligkeit allein ist deshalb kein Qualitätsmerkmal. Der Veröffentlichungsweg muss die hohe Erzeugungsrate aushalten, ohne ungeprüfte Zwischenstände mit dem öffentlichen Angebot zu vermischen.

Unveränderliche Revisionen statt flüchtiger Entwürfe

Jeder Markdown-Upload erzeugt in Contentkit eine neue, unveränderliche Revision. Eine bestehende Revision wird nicht überschrieben. Der öffentliche Stand verweist auf eine ausdrücklich veröffentlichte Revision. Damit bleiben der Entwurf, die Vorschau und die sichtbare Website unterscheidbar.

Das klingt nach einer technischen Feinheit, verändert aber den Umgang mit Agenten grundlegend. Angenommen, eine Produkt-API benennt ein Feld um. Ein Agent findet die betroffenen Seiten, aktualisiert achtzig Markdown-Dateien und erzeugt neue Revisionen. Bei Datei 63 enthält das Frontmatter einen ungültigen Elternverweis. Ein System, das direkt Seite für Seite aktualisiert, könnte bereits 62 Änderungen sichtbar gemacht haben. Contentkit baut den gesamten neuen Stand unter einem eigenen Speicherpräfix. Scheitert eine Prüfung, bleibt der aktive Release unverändert.

stateDiagram-v2
    [*] --> Draft: Markdown hochladen
    Draft --> Preview: Stand bauen
    Preview --> Release: freigeben
    Draft --> Draft: neue Revision
    Release --> Previous: neuer Release
    Previous --> Release: Zeiger zurücksetzen

Der Rollback ist deshalb kein erneuter Build und keine Rückwärtsmigration. Contentkit setzt den aktiven Zeiger auf einen bekannten Release zurück. Die Dateien dieses Standes existieren bereits. Für eine fehlerhafte Dokumentationsänderung ist das die schnellste Form der Schadensbegrenzung: Wirkung zurücknehmen, Ursache in Ruhe untersuchen, neue Revision veröffentlichen.

Ein praktisches Beispiel: API-Änderung bis Hilfeportal

Nehmen wir ein Team, das eine öffentliche API, ein Kundenhandbuch und ein Änderungsprotokoll pflegt. Die bisherige Arbeit verteilt sich auf Tickets, ein Wiki, manuelle Webseitenänderungen und die Hoffnung, dass alle Stellen gefunden wurden. Mit einem Agenten und Contentkit kann der Ablauf anders aussehen.

Der Agent liest den zusammengeführten API-Unterschied, die geänderte OpenAPI-Datei und die vorhandenen Markdown-Seiten. Er schlägt Änderungen an Referenzseiten, Migrationsanleitung und Changelog vor. Ein Prüfschritt vergleicht jeden erwähnten Endpunkt mit der aktuellen Spezifikation. Danach lädt der Agent die Dateien hoch und fordert eine Vorschau an. Ein Linktest sowie ein fachlicher Vertragscheck laufen gegen diesen vollständigen Stand. Erst wenn sie erfolgreich sind, darf ein Schlüssel mit release:write den Release aktivieren.

Für Anwender ist der Nutzen sehr konkret. Die Migrationsanleitung erscheint zusammen mit der geänderten Referenz. Alte Versionen bleiben unter ihrem dokumentierten Pfad erreichbar. Die Suche kennt keinen halbfertigen Zwischenstand. Falls die Anleitung fachlich falsch ist, lässt sich der vorherige Stand sofort aktivieren.

Diese Arbeit wird nicht nur schneller, weil ein Modell Text erzeugt. Sie wird einfacher, weil alle Schritte dieselbe darstellbare Form haben:

Der Unterschied zwischen alter und neuer API ist eine maschinenlesbare Eingabe.
Die vorgeschlagenen Änderungen sind Markdown und damit prüfbar.
Die Vorschau ist ein vollständiger Website-Stand, kein loses Dokument.
Der Release ist eine atomare Zustandsänderung mit nachvollziehbarem Grund.

Maschine zu Maschine heißt nicht ohne Verantwortung

Eine Oberfläche zwingt nicht automatisch zu Sorgfalt, und eine API nimmt sie nicht automatisch weg. Entscheidend ist, welche Berechtigungen und Prüfungen zwischen Vorschlag und Wirkung liegen. Contentkit trennt einen Schlüssel für die Verwaltung einer Website von Schlüsseln für Lesen, Schreiben und Veröffentlichen. Ein Agent, der Texte recherchiert, braucht keinen administrativen Zugriff. Ein Agent, der Revisionen hochlädt, muss noch lange keinen Release aktivieren dürfen.

In einer vollständig automatisierten Strecke kann die Freigabe ebenfalls maschinell erfolgen – etwa wenn alle Daten aus einer verifizierten Quelle stammen und die Vertragsprüfungen erfolgreich sind. Bei einer rechtlichen Seite oder einer sicherheitsrelevanten Betriebsanleitung wird wahrscheinlich eine ausdrückliche Freigabe bleiben. Beides benutzt denselben technischen Pfad. Die Organisation entscheidet, wo ein Mensch beteiligt sein muss; das CMS erzwingt keine manuelle Klickarbeit als Selbstzweck.

Genau darin liegt die Besonderheit von Contentkit. Das System versucht nicht, den Agenten wie einen Redakteur vor einem Bildschirm arbeiten zu lassen. Es behandelt ihn als technischen Teilnehmer mit begrenzten Rechten, klaren Eingaben und überprüfbaren Ergebnissen.

Weshalb LLMs davon besonders profitieren

Sprachmodelle arbeiten gut mit textuellen Verträgen. Markdown trägt Inhalt und Struktur, ohne die Menge an Nebendaten eines visuellen Editors. OpenAPI beschreibt die erlaubten Operationen. Klare Validierungsfehler geben einem Agenten eine Chance zur gezielten Korrektur. Unveränderliche Revisionen sorgen dafür, dass ein fehlgeschlagener Versuch nicht den letzten guten Stand verwischt.

Hinzu kommt die Ausgabe. Contentkit veröffentlicht nicht nur HTML für Menschen. Markdown-Zwillinge, llms.txt, llms-full.txt und die geschützte JSON-API machen denselben freigegebenen Stand für weitere Maschinen erreichbar. Ein Agent kann also Inhalt erzeugen, und ein anderer kann ihn später als freigegebene Quelle lesen – ohne HTML aus einer Autorenoberfläche herauslösen zu müssen.

Das Ergebnis ist kein „KI-CMS“ mit eingebautem Chatfenster. Contentkit muss kein Modell kennen. Es stellt einen kleinen, deterministischen Veröffentlichungsdienst bereit, an den unterschiedliche Modelle und Automatisierungen anschließen können. Claude Code kann heute die Dateien vorbereiten, Codex morgen die technischen Verweise prüfen, eine CI-Pipeline nächste Woche denselben Release-Weg verwenden. Der Vertrag bleibt.

Was im Betrieb beobachtbar bleibt

Ein maschinenorientierter Weg darf nicht zur schwarzen Box werden. Contentkit hält deshalb technische Kennungen an den entscheidenden Stellen fest: Der Upload liefert die Revisions-ID, Vorschau und Release besitzen eine eigene ID, Webhook-Ereignisse nennen den tatsächlichen Zustandswechsel. Ein Agentenlauf kann diese Werte in seinem Bericht speichern.

{
  "source_commit": "4a7d1b9",
  "agent_run": "docs-update-2026-07-17-01",
  "revision_ids": ["rev-a", "rev-b", "rev-c"],
  "preview_id": "preview-42",
  "release_id": "release-108",
  "checks": ["frontmatter", "links", "visibility"]
}

Dieser Nachweis muss nicht in Contentkit selbst liegen. Er kann Teil einer CI-Ausführung, eines Agentenprotokolls oder eines freigegebenen Reports sein. Entscheidend ist die gemeinsame Sprache aus IDs. Bei einer falschen Seite lässt sich vom öffentlichen Release zur Revision und von dort zum Agentenlauf zurückgehen.

Für den Betrieb ändert das die Fehlersuche. Die Frage lautet nicht mehr „Wer hat zuletzt im CMS gespeichert?“, sondern „Welche Revision wurde in welchem Release durch welchen Lauf aktiviert?“. Ein Supportfall kann die Release-ID nennen. Der Agent vergleicht den betroffenen Stand mit seinem Vorgänger und erzeugt eine Korrektur, ohne den alten Nachweis zu verändern.

Wo die fehlende Verwaltungsoberfläche Arbeit spart

Eine Oberfläche muss Felder, Rollen, Entwurfslisten, Massenbearbeitung, Plugin-Zustände und Versionskonflikte erklären. Diese Funktionen kosten Entwicklung und Betrieb – auch dann, wenn der eigentliche Autor ein Agent ist. Contentkit überlässt die Arbeitsumgebung bewusst vorhandenen Werkzeugen.

Claude Code oder Codex sieht den Git-Diff. Ein Team kann Pull Requests für fachlich wichtige Texte verwenden. Die CI kennt bereits Secrets, Testberichte und Freigaberegeln. Contentkit muss diese Oberfläche nicht ein zweites Mal nachbauen. Es beginnt an dem Punkt, an dem ein valides Dokument in eine veröffentlichbare Revision übergeht.

Das eignet sich nicht für jede Redaktion. Wer täglich visuell Seiten zusammenstellt und keine Dateiarbeit möchte, wird mit einem klassischen CMS schneller sein. Wer Inhalte hingegen aus Quellcode, Datenexporten, Agentenläufen oder versionierten Dokumenten erzeugt, spart eine Übersetzungsschicht. Der maschinenlesbare Stand muss nicht erst in eine menschliche Eingabemaske und anschließend wieder in technische Artefakte verwandelt werden.

Fazit

Contentkit ist für Maschinen gebaut, weil sein Steuerungsbereich keine menschliche Oberfläche voraussetzt. Markdown ist die portable Eingabe, HTTP der ausführbare Vertrag, die unveränderliche Revision der Nachweis und der atomare Release die kontrollierte Wirkung. Die fertige Website bleibt dabei ausdrücklich für Menschen gemacht.

Diese Trennung verkürzt den Weg von einer geprüften Änderung zur sichtbaren Dokumentation. Noch wichtiger: Sie macht den Weg nachvollziehbar. Ein Agent darf schnell sein, ohne dass Geschwindigkeit mit Öffentlichkeit verwechselt wird. Das ist eine unscheinbare, aber tragfähige Grundlage für Publishing mit LLMs.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare