By xwiki
Org-wide XWiki conventions, MCP servers and dev skills for all xwiki / xwiki-contrib GitHub org repos
Convert OLD XWiki documentation into the new xwiki.org documentation tree. Old documentation = pages under https://www.xwiki.org/xwiki/bin/view/Documentation/ and all extension pages under https://extensions.xwiki.org/xwiki/bin/view/Extension/ (the Extensions wiki). New documentation = https://www.xwiki.org/xwiki/bin/view/documentation/ (and pages nested under it). Use when migrating/refactoring a legacy page (or an extension page) into the new tree — treating the legacy content as source material, re-classifying it by Diataxis type, dropping obsolete content, and verifying nothing useful was lost. For authoring/reviewing a page that is already in the new tree, use xwiki-doc-writing instead.
Backport the automated test of one JIRA issue labelled `testneeded` to the currently-supported stable branches, adjust its `@since` tags across all branches, and open the PRs. Use when asked to backport the test of a given testneeded issue, or to catch a stable branch up with a recently-added test. (For several issues at once, the user will say so — then apply this per issue.) This is the test-specific layer on top of xwiki-backport (which owns the generic cherry-pick / adapt-to-branch / verify mechanics — including the mandatory pom-version, Java-version and `@since` checks). For Maven use xwiki-build; for PR/commit conventions use xwiki-pull-request; for the `@since` rules use xwiki-knowledge; for querying JIRA (the testneeded sweep) use xwiki-jira.
Backport any change (bug fix, feature, refactor, or test) to an older branch of an XWiki repo (xwiki-platform / xwiki-commons / xwiki-rendering / xwiki-contrib). Cherry-pick `-x` the source commit(s) into a worktree, ADAPT the result to the older branch (module pom versions, Java level, `@since` tags, style/API divergence), verify it compiles against that branch, and push / open a PR. Use whenever a commit that exists on one branch needs to be applied to an older/maintenance branch. For the `testneeded`-labelled test sweep use xwiki-backport-testneeded (which builds on this skill); for Maven commands use xwiki-build; for PR/commit conventions use xwiki-pull-request; for the versioning/`@since` conventions (the format and what carries `@since`) use xwiki-knowledge.
Build and test XWiki Maven modules. Use when building XWiki, running its tests, or when the user mentions mvn, a build, a failing test, or a specific XWiki module.
Announce an xwiki-contrib extension release by creating the "<Extension> Extension <version> Released" blog post on the xwiki.org Blog, following the contrib release-documentation convention (page name, title, content/summary templates, categories, publish date). Use after releasing an xwiki-contrib extension (groupId org.xwiki.contrib) when the blog-post step of the release documentation still needs doing. This is for contributed extensions only — not core xwiki-platform releases. For writing/reviewing general documentation pages use xwiki-doc-writing instead; for deploying a XAR/JAR to a running instance use xwiki-deploy-extension.
Modifies files
Hook triggers on file write and edit operations
External network access
Connects to servers outside your machine
Requires secrets
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Needs API keys or credentials to function
Needs API keys or credentials to function
Shared LLM configuration for XWiki developers, distributed as a Claude Code plugin marketplace, a Kimi Code plugin, and an opencode config.
The goal is consistency across developers, sharing the work of others, and simple onboarding — generic enough to work for every XWiki developer (no committed secrets, no personal paths). It was designed in the forum thread Organizing our LLM configs for all our repos.
The Claude marketplace manifest lives at the repo root (.claude-plugin/marketplace.json), the
Kimi plugin manifest lives at kimi.plugin.json, the opencode config lives at opencode.jsonc,
and the shared plugin content lives under xwiki/.
/plugin marketplace add https://github.com/xwiki/xwiki-dev-llm
/plugin install xwiki@xwiki-dev-llm
For local development against a checkout:
/plugin marketplace add /path/to/xwiki-dev-llm
/plugin install xwiki@xwiki-dev-llm
/plugins install https://github.com/xwiki/xwiki-dev-llm
/reload
For local development against a checkout:
/plugins install /path/to/xwiki-dev-llm
/reload
opencode has no plugin marketplace, so it reads this repo from a local checkout. Clone it once and
point XWIKI_LLM_HOME at it (the opencode.jsonc config resolves every path through that variable,
so the file stays portable — no personal paths):
git clone https://github.com/xwiki/xwiki-dev-llm ~/dev/xwiki/xwiki-dev-llm
# in your shell profile (~/.zshrc, ~/.bashrc, …):
export XWIKI_LLM_HOME="$HOME/dev/xwiki/xwiki-dev-llm"
Skills. opencode only discovers skills in fixed directories, so symlink this checkout's skills into your opencode config once (a single link — the skills and their OKF stay in the checkout):
mkdir -p ~/.config/opencode
ln -s "$XWIKI_LLM_HOME/xwiki/skills" ~/.config/opencode/skills
Config (MCP servers + org conventions). Choose one:
export OPENCODE_CONFIG="$XWIKI_LLM_HOME/opencode.jsonc"
Or merge the mcp and instructions entries from opencode.jsonc into your
~/.config/opencode/opencode.json.opencode.jsonc to opencode.json in an XWiki repo (it needs no editing —
it reads XWIKI_LLM_HOME). This scopes the config to that repo only.Line-ending guard (optional). Symlink the plugin into an opencode plugin directory:
mkdir -p ~/.config/opencode/plugins
ln -s "$XWIKI_LLM_HOME/xwiki/opencode/plugins/xwiki-line-endings.js" ~/.config/opencode/plugins/xwiki-line-endings.js
Note — no git-remote scoping in opencode. In Claude Code the org conventions are injected only inside
xwiki/*/xwiki-contrib/*repos (a remote-scopedSessionStarthook). opencode has no equivalent hook, so with the global config the conventions load in every repo. Use the per-project config if you need them scoped to XWiki repos only.
xwiki plugin providesnpx claudepluginhub xwiki/xwiki-dev-llm --plugin xwikiEvidence-gated AI coding workflow: scan → analyze → plan → TDD → execute → fix → verify → review, powered by Codebase Memory MCP >= 0.9.0 with optional Serena LSP intelligence. Includes blast-radius planning, test/cycle gates, independent review, and Windows Git Bash hook auto-resolution.
Lazy senior dev mode. Forces the simplest, shortest solution that actually works: YAGNI, stdlib first, no unrequested abstractions.
Access thousands of AI prompts and skills directly in your AI coding assistant. Search prompts, discover skills, save your own, and improve prompts with AI.
Upstash Context7 MCP server for up-to-date documentation lookup. Pull version-specific documentation and code examples directly from source repositories into your LLM context.
Consult multiple AI coding agents (Gemini, OpenAI, Grok, Perplexity, plus codex, antigravity, and grok CLIs when installed) to get diverse perspectives on coding problems
Reliable automation, in-depth debugging, and performance analysis in Chrome using Chrome DevTools and Puppeteer