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 |
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.
DOCS_COMMON.md (gemeinsame Regeln), dazu die Datei des Projekttyps.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.
| 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 |
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.
| 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.
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 | 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ü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.
| 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 |
git rev-parse HEAD im Projekt-Checkout.git status --short nicht leer), läuft die Prüfung gegen den Arbeitsstand, es wird aber nichts als verifiziert markiert.wikijs_mark_verified und dem updatedAt, das die Seite nach dem letzten Publish hat.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.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.
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.
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.