Branch: refs/heads/release-doc-skill-bugfix-and-noteworthiness Home: https://github.com/xwiki/xwiki-dev-llm Commit: e355c58e301ffb48932104250af43818db3d06af https://github.com/xwiki/xwiki-dev-llm/commit/e355c58e301ffb48932104250af438... Author: Vincent Massol <[email protected]> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- [Misc] Make the release-documentation sweep survive a bugfix release Three corrections found by running the skill for real, over the 17 issues fixed in 17.10.13. * Say that a bugfix release takes no entries. For an X.Y.Z with Z > 0 the release-note page renders {{jira}} instead of {{releasenotechanges/}}, so an entry posted there is stored and never rendered. The OKF said this; the skill did not act on it, and the sweep spent its triage proposing entries that could not appear. State where an entry would go instead (the .0 RC in the issue's Fix Version list) while making clear that this licenses no entry by itself, and that an already-released RC means a retroactive edit. * Search the identifiers the diff touches, not only the subject. The subject search answers "is there a page about this feature", which for a fix is usually "no" — and that "no" was being read as the documentation verdict. Searching the strings in the diff instead surfaced a page whose subject was a MySQL error but which carried one incidental sentence about the very statement the fix changed. * Replace the Bug trigger "user-visible behaviour or public API changed" with noteworthiness. Nearly every bug fix changes user-visible behaviour, that being what made it a bug, so the old wording fired on all of them. Add the query that measures the bar the project actually applies. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications