Dokumentation als Pipeline: zwei Agent-Skills im Zusammenspiel
Dokumentation veraltet, sobald der Code sich bewegt. Wir lösen das nicht mit Disziplin allein, sondern mit zwei kleinen Agent-Skills, die zusammen eine Pipeline bilden — von der Code-Änderung im Quell-Repo bis zur veröffentlichten Seite hier auf docs.processcube.io.
Die zwei Hälften
In der Mitte steht das README.md (bei größeren Projekten zusätzlich
DEVELOPMENT.md) des Quell-Repos als Source of Truth. Zwei Skills bedienen
jeweils eine Seite davon:
repo-dokuläuft im Quell-Repo. Es wertet vorhandene Doku, Changelog, Git-Commits seit dem letzten Stand und den Quellcode aus und schreibt das README fort — minimal-invasiv und ohne erfundene APIs.doku-uebernehmenläuft hier im Doku-Repo. Es überführt genau diese Doku als MDX-Seiten, pflegt Navigation und Suche — und repariert Veraltetes nicht selbst, sondern spielt es anrepo-dokuzurück.
repo-doku ist agent-agnostisch (Claude Code, Codex, OpenClaw) und per
npx skills add processcube-io/ProcessCube.Agent.Skills --skill repo-doku
installierbar. doku-uebernehmen ist das docs.processcube.io-interne
Gegenstück.
Der Release als Bindeglied
Zwischen „Doku im Quell-Repo gepflegt” und „Seite auf docs.processcube.io” liegt ein klar abgegrenzter Schritt: der Release. Genau dieser verbindet die beiden Hälften — und weil ProcessCube® eine BPMN-Engine ist, beschreiben wir ihn als einfachen Prozess:
Das exklusive Gateway bildet das Prinzip „kein Gap” ab: Hat sich seit dem letzten
Stand nichts Dokumentationsrelevantes geändert, endet der Prozess sofort — statt
die Doku künstlich umzuschreiben. Andernfalls bündelt der Release die
Quell-Doku zu einem versionierten Stand, den doku-uebernehmen anschließend in
die Doku-Site überführt und veröffentlicht.
Ein echter Durchlauf: der .NET-Client
Das hier ist kein konstruiertes Beispiel — genau so ist die TestCaseFixture-Seite entstanden.
Code ändert sich
Im .NET-Client werden in v5.0.0 zwei Worker-Settings konfigurierbar
(LockRenewalThreshold, LockSchedulerScanInterval), und die
TestCaseFixture bekommt ein neues Default-Image auf dem ProcessCube®
Marketplace.
repo-doku im Quell-Repo
repo-doku vergleicht den letzten README-Stand mit der Git-Historie,
verifiziert die neuen Settings am Quellcode und ergänzt das README: einen
neuen Abschnitt zur TestCaseFixture und den Hinweis, dass die Lock-Timings
konfigurierbar sind. Der bewährte Rest des READMEs bleibt unangetastet.
doku-uebernehmen im Doku-Repo
doku-uebernehmen erkennt die zwei Deltas und platziert sie passend in die
kuratierte .NET-Doku: eine neue Seite „Integrationstests” und ein
präzisierter Satz im Abschnitt „Lock-Management”. Kein README-Dump — die
bestehende, feiner gegliederte Struktur wird respektiert.
Veröffentlichen
UI-Test, Commit, Release, Deploy. Die Seite ist live, die Suche kennt sie.
Warum das funktioniert
- Eine Quelle der Wahrheit. Die Doku lebt dort, wo der Code liegt. Die Doku-Site ist eine Projektion, kein zweiter Pflege-Ort.
- Minimal-invasiv. Beide Skills ändern nur, was die neuen Commits betreffen. Ist nichts Neues da, ist „kein Gap” ein gültiges Ergebnis — es wird nichts künstlich umgeschrieben.
- Verifiziert statt erfunden. Beispiele und Signaturen werden am Quellcode geprüft, nicht halluziniert.
- Klare Richtung. Korrekturen fließen immer zurück zur Quelle, nie nur in die Projektion — so driften die beiden nicht auseinander.
Das Ergebnis: Dokumentation, die mit dem Code Schritt hält, weil das Pflegen und das Veröffentlichen zwei klar getrennte, automatisierbare Schritte sind.