Wiki.js Plugin: Skills

Referenz der vier Skills des Wiki.js Plugins: docs-wiki, source-check (inkl. baseline), translation-check und setup, mit Aufruf, Ablauf, Verdikten und Projekttypen.

English Version

Zurück zur Übersicht

Wiki.js Plugin: Skills

Diese Dokumentation bezieht sich immer auf die aktuellste veröffentlichte Version.

Das Plugin bringt vier Skills mit. Alle sind direkt aufrufbar.

Skill	Aufruf	Zweck
`docs-wiki`	`/wikijs-plugin:docs-wiki`	Doku für Wiki.js erstellen oder aktualisieren (DE + EN)
`source-check`	`/wikijs-plugin:source-check [baseline] <projekt oder wiki-pfad>`	Seiten gegen den Quellcode prüfen
`translation-check`	`/wikijs-plugin:translation-check <wiki-pfad> <locale>`	Natürlichkeit von DE- und EN-Text prüfen
`setup`	`/wikijs-plugin:setup`	Erst-Einrichtung und Reparatur

docs-wiki

Erstellt oder aktualisiert Wiki.js-Dokumentation mit Dokumentations-Agents und veröffentlicht sie über die MCP-Tools in DE und EN. Jede Doku besteht aus einem Hub und Unterseiten mit identischen Pfaden in beiden Sprachen.

Ablauf

Projekttyp erkennen oder erfragen: osTicket, Shopware6, OXID, Sylius, MCP, Bash/Shell, Claude Agent. Ist der Typ aus dem Kontext klar, wird nicht nachgefragt.
Projekt bestimmen, inklusive lokalem Checkout (Pfad, Git-Repo). Den Pfad erfragt der Skill, er rät ihn nicht.
Modus wählen: Neue Doku, Update oder Qualitäts-Upgrade.
Templates laden: immer DOCS_COMMON.md (gemeinsame Regeln), dazu die Datei des Projekttyps.
Content erzeugen (Hub + Unterseiten, DE + EN). Eine vorhandene Einzelseite wird dabei zu Hub + Unterseiten umgebaut.
source-check über den gesamten Seitensatz (Pflicht, vor translation-check).
translation-check über den gesamten Seitensatz (Pflicht, vor dem ersten Publish).
Publish mit isPublished: true, bei vorhandenem Git-Stand mit sourceRepo, sourceRef und summary. Danach updatedAt lesen und mit wikijs_mark_verified den geprüften Ref setzen, außer bei uncommittetem Projekt-Checkout.

Ein Aufruf wie /docs-wiki osTicket api-endpoints Qualitäts-Upgrade überspringt die Fragen, deren Antwort schon dasteht.

Agents

Agent	Einsatz
`docs-architect`	immer, analysiert den Code und schreibt die Hauptdokumentation
`mermaid-expert`	immer, mindestens ein Diagramm für den Hub und eines für die Technik-Seite
`tutorial-engineer`	bei Neue Doku und Qualitäts-Upgrade, Schritt-für-Schritt-Anleitungen
`api-documenter`	nur bei Projekten mit API
`reference-builder`	bei umfangreicher Konfiguration

Templates

Es gibt sieben typ-spezifische Templates: osTicket, Shopware6, OXID, Sylius, MCP, Bash/Shell und Claude Agent. Wer einen neuen Projekttyp ergänzen will, legt unter templates/ einen Ordner mit einer Template-Datei an und trägt ihn in die Mapping-Tabelle des Skills ein.

Modi

Modus	Was passiert
Neue Doku	Ein Inventar wird aus dem Code gebaut, daraus entsteht der Seitenplan, danach folgt die Content-Erzeugung für alle Seiten
Update	Bestehende Seite laden, Änderungen einarbeiten, Einzelseiten vorher zu Hub + Unterseiten umbauen
Qualitäts-Upgrade	Lücken finden (Diagramme, Callouts, Tabs, Troubleshooting) und gezielt schließen

Ist der MCP-Server nicht erreichbar, blockiert das nur den Publish-Schritt. Der Skill erzeugt trotzdem den vollständigen Content und gibt ihn als Markdown zum manuellen Kopieren aus.

source-check

Prüft die Fakten von Wiki.js-Seiten gegen den Quellcode des dokumentierten Projekts. Die README zählt als Behauptung, der Code gewinnt. Der Skill findet Fehler, die in DE und EN gleich lauten und deshalb dem translation-check entgehen.

Aufruf

Aufruf	Wirkung
`/wikijs-plugin:source-check <projekt oder wiki-pfad>`	Prüft einen Seitensatz
`/wikijs-plugin:source-check baseline`	Baseline-Lauf über alle vorhandenen Seiten

Prüfungen

Prüfung	Inhalt
Claim-Check	Dateipfade, Klassen, Config-Keys, Befehle, Umgebungsvariablen, Routen, Standardwerte und Zahlen werden im Code nachgeschlagen und als bestätigt, abweichend oder nicht auffindbar eingestuft
Inventar-Check	Ein Inventar dessen, was das Projekt für Anwender bereitstellt (Befehle, Routen, Config-Keys, Umgebungsvariablen, Erweiterungspunkte, Entities, je nach Projekttyp mehr), wird gegen den Seitensatz gehalten. Was im Code existiert und nirgends steht, wird als undokumentiert gemeldet
Diff-Update	Bei Seiten mit gültigem verifiziertem Ref wird nur der Code-Diff seit diesem Ref plus jeder geänderte Seitenabschnitt geprüft

Der Inventar-Check ist heuristisch. Undokumentierte Punkte ändern weder das Verdikt noch das Markieren. Die Entscheidung, ein Punkt bleibe bewusst intern, wird nicht gespeichert und erscheint beim nächsten vollständigen Lauf erneut.

Verdikte

Verdikt	Bedeutung	Folge
PASS	Alle Behauptungen stimmen	weiter mit translation-check, Publish, `wikijs_mark_verified`
WARN	Behauptungen nicht belegbar	Fundstellen werden gesammelt gezeigt, du entscheidest. Markiert wird erst nach deiner Freigabe
FAIL	Mindestens eine abweichende Behauptung	Nicht publizieren, mit dem Wert aus dem Code korrigieren, erneut prüfen

Vorbereitung und Markierung

Der Skill ermittelt den Ref mit git rev-parse HEAD im Projekt-Checkout.
Ist der Checkout nicht sauber (git status --short nicht leer), läuft die Prüfung gegen den Arbeitsstand, es wird aber nichts als verifiziert markiert.
Ohne Git-Repo oder Checkout läuft der Claim-Check, nichts wird markiert.
Markiert wird mit wikijs_mark_verified und dem updatedAt, das die Seite nach dem letzten Publish hat.
Der Marker zählt nur, solange das Live-updatedAt dazu passt. Jede Änderung der Seite, auch ein reines Links- oder Tag-Update, macht ihn ungültig und kostet beim nächsten Update einen vollständigen Check.
Die verifizierten Stände liegen in der lokalen Datenbank und gelten pro Rechner.

Baseline-Lauf

Der Lauf geht alle Seiten je Projekt durch und ändert keine Seite. Er listet die Seiten je Sprache mit wikijs_list_pages (limit: 200, mit offset weiterblättern), überspringt Seiten mit gültigem Marker, gruppiert nach Projekt, baut je Projekt das Inventar und prüft die ungeprüften Seiten in einem Durchgang. Bestandene Seiten werden markiert, Fundstellen nur berichtet. Projekte ohne lokalen Checkout oder ohne Git-Repo werden getrennt als nicht prüfbar aufgeführt. Am Ende steht die Aufteilung bereits verifiziert | bestanden | mit Fundstellen | nicht prüfbar je Sprache.

translation-check

Prüft, ob DE- und EN-Seiten natürlich klingen und nicht wie wörtliche Übersetzungen. docs-wiki ruft ihn als Pflicht-Gate vor jedem Publish auf. Standalone nimmst du eine Wiki.js-Seite (Pfad und Locale) oder eingefügten Text.

Prüfung	Ergebnis
Glossar: Begriffe, die als Lehnwort bleiben müssen (z. B. Cronjob, Branch, Commit), und etablierte deutsche Formen	Treffer in der Spalte Falsch: FAIL
Holistisches Lesen auf Calques und Stilmuster	ein Muster: WARN, mehrere oder durchgängig: FAIL
EN-Text auf Germanismen und falsche Freunde	höchstens WARN
DE/EN-Abgleich: Abschnitte, Überschriften, Tabellenzeilen, Codeblöcke, Pfade, Zahlen	Abweichung: FAIL, nur andere Formulierung: kein Fund
Escape-Reste (Backslash vor Anführungszeichen) im Fließtext	FAIL

Treffer in Codeblöcken, Inline-Code, URLs und Pfaden zählen nicht.

Eigene Glossar-Einträge legst du in ~/.wikijs-plugin/glossary.local.md an (gleiche Tabellenform, optional). Sie gelten vor dem mitgelieferten Glossar. In die mitgelieferte Datei wird nicht geschrieben, sie wird beim Plugin-Update überschrieben.

setup

Richtet das Plugin ein oder repariert es: Python ermitteln, Venv anlegen, Abhängigkeiten synchronisieren, .env-Vorlage kopieren, Import prüfen. Details stehen auf der Seite Installation.

Typische Abläufe mit den Skills beschreibt die Seite Arbeitsabläufe.