Wiki.js Plugin: Skills

Reference for the four skills of the Wiki.js plugin: docs-wiki, source-check (incl. baseline), translation-check and setup, with invocation, flow, verdicts and project types.

Deutsche Version

Back to overview

Wiki.js Plugin: Skills

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

docs-wiki

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.

Flow

Project type: detect or ask: osTicket, Shopware6, OXID, Sylius, MCP, Bash/Shell, Claude Agent. If the type is clear from context, the skill does not ask again.
Project: determine it, including the local checkout (path, Git repo). The skill asks for the path, it does not guess.
Mode: choose New docs, Update or Quality upgrade.
Templates: load DOCS_COMMON.md (shared rules) always, plus the file for the project type.
Generate content (hub + sub-pages, DE + EN). An existing single page is rebuilt into hub + sub-pages in the process.
source-check over the whole page set (mandatory, before translation-check).
translation-check over the whole page set (mandatory, before the first publish).
Publish with 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.

Agents

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

Templates

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.

Modes

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.

source-check

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

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

Checks

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.

Verdicts

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

Preparation and marking

The skill determines the ref with git rev-parse HEAD in the project checkout.
If the checkout is not clean (git status --short is not empty), the check runs against the working state, but nothing is marked as verified.
Without a Git repo or checkout the claim check runs, nothing is marked.
Marking uses wikijs_mark_verified and the updatedAt the page has after the last publish.
The marker only counts while the live 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.
Verified states live in the local database and apply per machine.

Baseline run

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.

translation-check

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.

setup

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.