Entwickler-Skills (Marketplace)

Installierbare Skills, die Coding-Agenten wie Claude Code, Codex und OpenClaw wiederkehrende Entwickler-Workflows abnehmen: Releases erstellen, Changelogs pflegen und Dokumentation aus dem Repo erzeugen.

Die Skills folgen dem Agent Skills Open Standard (jeweils ein Verzeichnis mit SKILL.md) und werden aus dem Repository processcube-io/ProcessCube.Agent.Skills installiert.

Nicht zu verwechseln mit den CLI-AI-Skills: Jene (engine, studio, knowledge) sind in der pc-CLI gebündelt und geben dem Agenten Wissen über die CLI-Befehle. Die Entwickler-Skills hier werden per npx skills installiert und automatisieren Repo-Workflows unabhängig von der CLI.

Verfügbare Skills

Skill	Beschreibung	Auslöser
`repo-doku`	Erstellt/aktualisiert die Doku (README, ggf. `DEVELOPMENT.md`) im Quell-Repo aus Commits, Changelog und Quellcode	`/repo-doku` oder „Aktualisiere das README”
`release-process`	Erstellt Releases (Stable, Insiders, Development) im Single-Branch-Workflow (nur `main`)	`/release-process` oder „Erstelle ein Release”
`changelog`	Erstellt oder aktualisiert ein Changelog aus der Git-Historie	`/changelog` oder „Erstelle ein Changelog”

Installation

Alle Skills


npx skills add processcube-io/ProcessCube.Agent.Skills

Einzelner Skill


npx skills add processcube-io/ProcessCube.Agent.Skills --skill repo-doku
npx skills add processcube-io/ProcessCube.Agent.Skills --skill release-process
npx skills add processcube-io/ProcessCube.Agent.Skills --skill changelog

Manuell

Repository klonen und das gewünschte Skill-Verzeichnis nach .claude/skills/ (bzw. ~/.openclaw/skills/) kopieren:


git clone https://github.com/processcube-io/ProcessCube.Agent.Skills.git
cp -r ProcessCube.Agent.Skills/skills/repo-doku /pfad/zum/projekt/.claude/skills/

Aktualisieren:


npx skills update

repo-doku im Detail

repo-doku pflegt die Dokumentation dort, wo der Code liegt — im Quell-Repo als „Source of Truth”. Der Agent schreibt minimal-invasiv und erfindet keine APIs.

Quellen

Der Skill wertet in dieser Reihenfolge aus:

Vorhandene Doku (README.md, ggf. DEVELOPMENT.md) als Ausgangsbasis
Changelog-Dateien als strukturierte Quelle für Neuerungen
Git-Commits seit dem letzten Doku-Stand
Quellcode für die Details (öffentliche API, Optionen, Beispiele)

Ablauf

Doku-Ziel bestimmen

README.md (Bibliotheken, CLIs, kleine Services) oder zusätzlich DEVELOPMENT.md (größere Anwendungen, Plattformen).

Lücke ermitteln

Über die Git-Historie den letzten Doku-Stand finden und nur die Änderungen seitdem betrachten.

Schreiben

Vorhandene Struktur fortschreiben, Beispiele aus echtem Code ableiten, Projekt-Konventionen einhalten.

Abschluss

Conventional-Commit vorschlagen — der Agent committet nicht selbst.

„Kein Gap” ist ein gültiges Ergebnis. Sind seit dem letzten Stand nur interne Bugfixes, Tests oder Releases dazugekommen, ändert der Skill bewusst nichts und meldet das zurück — statt die Doku künstlich aufzublähen.

Beispiel


/repo-doku

Aktualisiere das README für die letzten Releases.

Der Agent vergleicht den letzten README-Stand mit der Git-Historie, dokumentiert nur die neuen, nutzerrelevanten Features (verifiziert am Quellcode) und schlägt am Ende einen Commit wie docs: README um Feature X ergänzen vor.

release-process im Detail

release-process erstellt Releases nach Semantic Versioning in einem Single-Branch-Workflow (nur main).

Release-Typen

Typ	Format	Basis
Stable	`MAJOR.MINOR.PATCH` (`1.2.0`)	aus den Commits seit dem letzten Stable-Tag
Insiders	`X.Y+1.0-insiders.N` (`1.3.0-insiders.1`)	letzte Stable-Version, Minor erhöht
Development	`X.Y+1.0-develop.N` (`1.3.0-develop.1`)	letzte Stable-Version, Minor erhöht

Die Versionsstufe leitet der Agent aus den Commits ab: MAJOR bei Breaking Changes (feat!, BREAKING CHANGE), MINOR bei neuen Features (feat), PATCH bei Fixes und internen Änderungen.

Ablauf

Vorbereitung

Branch prüfen, uncommitted Changes ggf. stashen, git pull origin main.

Version bestimmen

Aktuelle Version (z.B. aus package.json) und Tags lesen, Commits seit dem letzten Tag analysieren, neue Version festlegen.

Changelogs pflegen

Beide Changelogs aktualisieren — Changelog.md (Nutzersicht) und Changelog-Dev.md (Entwicklersicht), sofern im Projekt vorhanden.

Version setzen & taggen

package.json (und weitere Versionsdateien) bumpen, chore: release vX.Y.Z committen, Tag erstellen, main + Tag pushen.

Gepusht wird erst nach expliziter Bestätigung. Der Agent committet/pusht nicht ungefragt — passend zur Projektregel „kein automatisches Commit/Push”.

changelog im Detail

changelog erzeugt oder aktualisiert ein Changelog aus der Git-Historie — gruppiert nach Versionen und kategorisiert nach Änderungstyp.

Zielgruppe & Datei

Zielgruppe	Datei	Inhalt
Anwender	`Changelog.md`	Nutzen beschreiben, keine Commit-Hashes
Entwickler	`Changelog-Dev.md`	technische Details, Commit-Hashes, PR-Nummern, Breaking Changes

Phasen

Features durchlaufen drei Phasen — jedes Feature wird nur in einer gelistet:


🔮 In Entwicklung  →  🧪 Insiders  →  ✅ Stable
     (Ausblick)        (Early Adopter)    (Alle Nutzer)

Vorgehen

Modus „Aktualisieren” (Standard): nur neue Commits seit dem letzten dokumentierten Stand ergänzen; „Neu erstellen” baut das Changelog ab einem Zeitpunkt komplett auf.
Commits werden kategorisiert (Neue Funktionen, Fehlerbehebungen, Performance, Technisch).
Ignoriert werden Merge-, Release- und WIP-Commits.

Beispiel


/changelog

Wir haben v2.4.0-insiders.3 released.

Der Agent verschiebt die Einträge aus „In Entwicklung” in den neuen Abschnitt „Insiders v2.4.0-insiders.3”, legt einen leeren „In Entwicklung”-Abschnitt an und ergänzt das Datum.

Zusammenspiel: die Doku-Pipeline

repo-doku hat ein Gegenstück: doku-uebernehmen. Zusammen bilden sie eine durchgängige Pipeline von der Code-Änderung bis zur veröffentlichten Doku-Seite — mit dem README/DEVELOPMENT.md des Quell-Repos als Source of Truth in der Mitte.

Skill	Läuft in	Aufgabe
`repo-doku`	Quell-Repo	README/`DEVELOPMENT.md` aus Commits, Changelog und Quellcode pflegen
`doku-uebernehmen`	docs.processcube.io	diese Doku als MDX-Seiten übernehmen, `_meta`/Suche pflegen

doku-uebernehmen

Konvertiert die Quell-Doku nach MDX, pflegt die _meta-Navigation, registriert bei neuen Bereichen die Such-Collection und führt einen UI-Test durch — bis commit-bereit. Inhaltlich Veraltetes wird nicht in der Doku-Site repariert, sondern an repo-doku im Quell-Repo zurückgespielt.

doku-uebernehmen ist das docs.processcube.io-interne Gegenstück (kennt Struktur, Komponenten-Map und Deploy dieses Repos) und liegt im docs-Repo unter .claude/skills/ — es ist nicht Teil des öffentlichen Marketplace. repo-doku dagegen ist agent-agnostisch und per npx skills installierbar.

Der Release als Bindeglied

Zwischen den beiden Skills liegt ein abgegrenzter Schritt — der Release. Als BPMN-Prozess (ProcessCube® ist eine BPMN-Engine):

Das exklusive Gateway bildet das Prinzip „kein Gap” ab: ohne dokumentationsrelevante Änderung endet der Prozess sofort.