This documentation always describes the latest published version.
The plugin ships four skills. All of them can be invoked directly.
| Skill | Invocation | Purpose |
|---|---|---|
docs-wiki |
/wikijs-plugin:docs-wiki |
Create or update Wiki.js documentation (DE + EN) |
source-check |
/wikijs-plugin:source-check [baseline] <project or wiki path> |
Check pages against the source code |
translation-check |
/wikijs-plugin:translation-check <wiki path> <locale> |
Check DE and EN text for natural wording |
setup |
/wikijs-plugin:setup |
First-time setup and repair |
Creates or updates Wiki.js documentation with documentation agents and publishes it in DE and EN through the MCP tools. Each documentation set consists of a hub and sub-pages with identical paths in both languages.
DOCS_COMMON.md (shared rules) always, plus the file for the project type.isPublished: true, and with sourceRepo, sourceRef and summary when a Git state is available. Afterwards read updatedAt and set the checked ref with wikijs_mark_verified, except for an uncommitted project checkout.A call such as /docs-wiki osTicket api-endpoints Qualitäts-Upgrade skips the questions whose answer is already given.
| Agent | Use |
|---|---|
docs-architect |
always, analyses the code and writes the main documentation |
mermaid-expert |
always, at least one diagram for the hub and one for the technical page |
tutorial-engineer |
for new docs and quality upgrade, step-by-step guides |
api-documenter |
only for projects with an API |
reference-builder |
for extensive configuration |
There are seven project-type templates: osTicket, Shopware6, OXID, Sylius, MCP, Bash/Shell and Claude Agent. To add a new project type, create a folder with a template file under templates/ and add it to the mapping table of the skill.
| Mode | What happens |
|---|---|
| New docs | An inventory is built from the code, it drives the page plan, then content is generated for all pages |
| Update | Load the existing page, work in the changes, rebuild single pages into hub + sub-pages first |
| Quality upgrade | Find gaps (diagrams, callouts, tabs, troubleshooting) and close them selectively |
If the MCP server is not reachable, only the publish step is blocked. The skill still generates the complete content and outputs it as Markdown for manual copying.
Checks the facts of Wiki.js pages against the source code of the documented project. The README counts as a claim, the code wins. The skill finds errors that read the same in DE and EN and therefore escape translation-check.
| Invocation | Effect |
|---|---|
/wikijs-plugin:source-check <project or wiki path> |
Checks one page set |
/wikijs-plugin:source-check baseline |
Baseline run over all existing pages |
| Check | Content |
|---|---|
| Claim check | File paths, classes, config keys, commands, environment variables, routes, default values and numbers are looked up in the code and rated confirmed, deviating or not found |
| Inventory check | An inventory of what the project provides to users (commands, routes, config keys, environment variables, extension points, entities, more depending on the project type) is held against the page set. What exists in the code and is mentioned nowhere is reported as undocumented |
| Diff update | For pages with a valid verified ref, only the code diff since that ref plus every changed page section is checked |
The inventory check is heuristic. Undocumented items change neither the verdict nor the marking. The decision that an item stays internal on purpose is not stored and shows up again on the next full run.
| Verdict | Meaning | Consequence |
|---|---|---|
| PASS | All claims are correct | continue with translation-check, publish, wikijs_mark_verified |
| WARN | Claims that cannot be verified | Findings are shown together, you decide. Marking happens only after your approval |
| FAIL | At least one deviating claim | Do not publish, correct with the value from the code, check again |
git rev-parse HEAD in the project checkout.git status --short is not empty), the check runs against the working state, but nothing is marked as verified.wikijs_mark_verified and the updatedAt the page has after the last publish.updatedAt matches. Any change to the page, even a pure link or tag update, invalidates it and costs a full check at the next update.The run goes through all pages project by project and changes no page. It lists the pages per language with wikijs_list_pages (limit: 200, paging with offset), skips pages with a valid marker, groups by project, builds the inventory per project and checks the unchecked pages in one pass. Passed pages are marked, findings are only reported. Projects without a local checkout or without a Git repo are listed separately as not checkable. The end result is the split already verified | passed | with findings | not checkable per language.
Checks whether DE and EN pages sound natural instead of like literal translations. docs-wiki calls it as a mandatory gate before every publish. Standalone you pass a Wiki.js page (path and locale) or pasted text.
| Check | Result |
|---|---|
| Glossary: terms that must stay loanwords (e.g. Cronjob, Branch, Commit) and established German forms | Hit in the Wrong column: FAIL |
| Holistic reading for calques and style patterns | one pattern: WARN, several or throughout: FAIL |
| EN text for Germanisms and false friends | at most WARN |
| DE/EN comparison: sections, headings, table rows, code blocks, paths, numbers | Deviation: FAIL, only different wording: no finding |
| Escape leftovers (backslash before a quote) in running text | FAIL |
Hits inside code blocks, inline code, URLs and paths do not count.
You add your own glossary entries in ~/.wikijs-plugin/glossary.local.md (same table form, optional). They take precedence over the shipped glossary. The shipped file is never written to, it is overwritten on plugin update.
Sets up or repairs the plugin: find Python, create the venv, sync dependencies, copy the .env template, check the import. Details are on the Installation page.
Typical flows with the skills are described on the Workflows page.