September 2026 - notifications

[xwiki/xwiki-dev-llm] d2e53d: [Misc] Make the release-documentation sweep surviv...
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/release-doc-skill-bugfix-and-noteworthiness Home: https://github.com/xwiki/xwiki-dev-llm Commit: d2e53d041f1c621684ed8628f24f98206ecbb71f https://github.com/xwiki/xwiki-dev-llm/commit/d2e53d041f1c621684ed8628f24f9… Author: Vincent Massol <vincent(a)massol.net> 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 what a bugfix release does with entries. For an X.Y.Z with Z > 0 the release-note page renders {{jira}} instead of {{releasenotechanges/}}, so an entry posted against that version is stored and never rendered. That is a fact about the page, not about the issues: a bugfix release is mostly bug fixes, which go to N/A on their own merits, but improvements do get slipped in when they are what fixes the bug and those need their entry like any other — against the .0 or RC version the issue is also fixed in, which is where it renders. Every improvement of the recent bugfix releases that carries an entry URL points there, and no bugfix note stores an entry. * 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) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] e355c5: [Misc] Make the release-documentation sweep surviv...
by XWiki Notifications 10 Sep '26

10 Sep '26

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/e355c58e301ffb48932104250af43… Author: Vincent Massol <vincent(a)massol.net> 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) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm]
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/tags/v1.9.0 Home: https://github.com/xwiki/xwiki-dev-llm To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] c9eef0: [Misc] Release 1.9.0
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-dev-llm Commit: c9eef0aa93c3f28d47c52cfc24615fd29015d826 https://github.com/xwiki/xwiki-dev-llm/commit/c9eef0aa93c3f28d47c52cfc24615… Author: github-actions[bot] <41898282+github-actions[bot](a)users.noreply.github.com> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M .claude-plugin/marketplace.json M kimi.plugin.json M opencode.jsonc M xwiki/.claude-plugin/plugin.json Log Message: ----------- [Misc] Release 1.9.0 * skill added: xwiki-release-documentation To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm]
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/release-documentation-skill Home: https://github.com/xwiki/xwiki-dev-llm To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] ab3c72: Add the xwiki-release-documentation skill, now tha...
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-dev-llm Commit: ab3c72854195feb9044267285b488ea9815edc41 https://github.com/xwiki/xwiki-dev-llm/commit/ab3c72854195feb9044267285b488… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M README.md M xwiki/instructions/xwiki-org.md M xwiki/okf/index.md A xwiki/okf/processes/release-notes.md M xwiki/okf/servers/jira.md M xwiki/skills/xwiki-contrib-release-blog-post/SKILL.md M xwiki/skills/xwiki-doc-convert/SKILL.md M xwiki/skills/xwiki-doc-writing/SKILL.md M xwiki/skills/xwiki-jira/SKILL.md A xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- Add the xwiki-release-documentation skill, now that the RN endpoints exist The documentation of a release was a manual sweep whose only record was two JIRA fields nobody could query, because the habit of writing "N/A (internal class)" into them means "N/A" does not match. Release Notes Application 2.7 added the REST endpoints that make the other half of it mechanisable: one call creates a release note, one creates a change, and neither leaves an entry half made or two authors racing for the same Entry### number. * Add xwiki/skills/xwiki-release-documentation/SKILL.md, explicit-invocation only, in two modes: a whole Fix Version (the issues the developer fixed in it, across XWIKI/XCOMMONS/XRENDERING) or one named issue. It reads the full diff of every issue including the ones heading for N/A, since an N/A verdict is a claim that has to be proven; traces every written fact to file:line at the release ref; has a fresh verifier check the prose it did not write; and re-derives the existing field values rather than trusting them, which makes the run an audit and not a gap-filler. * Add xwiki/okf/processes/release-notes.md, the declarative half: the page tree a release note is, why entries belong to the RC and not to the final version, the four endpoints with the traps a client has to know (a POST answers the stored value, a duplicate note is a 409, changes are never deduplicated, a listing on a missing note is an empty 200), and how an entry's escaped reference becomes the URL a JIRA field wants. * Record the bare-N/A rule and the two custom field ids in okf/servers/jira.md. Bare N/A is what makes "every fixed issue nobody documented" a query; the reason moves to a comment. * Say in the OKF that the category vocabulary has drifted from the JIRA components it looks like (Blocknote vs BlockNote, LiveData vs Live Data) and give the recipe that harvests it, rather than caching a list that goes stale every cycle. * Point xwiki-doc-writing, xwiki-doc-convert, xwiki-jira and xwiki-contrib-release-blog-post at the new skill, and drop one redundant sentence from xwiki-org.md, which had two bytes of its budget left. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 300c9970ab9543a584c6b343466399485979a57e https://github.com/xwiki/xwiki-dev-llm/commit/300c9970ab9543a584c6b34346639… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- Remove the duplication between the skill and the OKF, and fix the screenshots order The field-value rules were stated three times (skill, okf/processes/release-notes.md, okf/servers/jira.md) and the entry conventions twice, which is how the three drift apart. The skill is the procedure and now defers, the way xwiki-fix-sonarqube-issue defers to okf/sonarqube/. * Keep the JIRA field-value rules in okf/servers/jira.md alone, where the other issue-field conventions are; release-notes.md keeps only what is specific to it, which is that the two verdicts are independent and that the entry URL is read back rather than built. * Drop from the skill the entry field conventions, the category-drift examples and the release-manager leftovers, all of which the OKF states in full. What stays is the operative one-liner a writer cannot afford to miss, and the steps themselves. * Give the skill the plugin-root resolution for okf/ that xwiki-fix-sonarqube-issue has, since deferring more content makes a pointer nobody can follow worse than a repetition. * Fix the screenshots step, which the deduplication exposed as impossible: a screenshots name has to name an attachment on a page that does not exist until the POST allocates it, and the RN resources carry GET and POST only. Post the change without them, attach to the page named by reference, then set the property through the generic object REST API — and never pre-create the entry page, which would corrupt the Entry### allocation. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 430e9bcbfbba52e98391cf10ad73a9db2ddac344 https://github.com/xwiki/xwiki-dev-llm/commit/430e9bcbfbba52e98391cf10ad73a… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- Say where a release-note screenshot comes from, and file RN-119 for the missing PUT A change about something visible in the UI is expected to carry a screenshot, and the skill said only that one gets attached, which leaves an author free to shoot a fresh one. Two screenshots of the same feature taken at different moments disagree about width, theme, sample data and what is hovered, so the release note would illustrate something subtly unlike the documentation it links. * Record in the OKF that the screenshot is produced for the reference documentation first and the release note reuses that exact image, never its own. * Record that it is copied onto the entry page rather than linked to the documentation page. A release note is the record of one moment: when the documentation screenshot is refreshed for a later UI, every past release note must still show the UI as it was at that release, and a link would silently rewrite what old release notes claim. * Make §6.1 run before §6.2 for such a change in the skill, since that is where the image is made, and spell out the copy as a download-then-upload against the page the POST returned. * Flag, rather than derive, the screenshots of a UI-visible change whose documentation verdict was N/A: it has no image to reuse, which usually means the verdict is wrong. * Reference RN-119, filed for the missing PUT endpoint that forces the property to be written through the generic object API. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: ae021ce8565ca24653c8a3b4700fe96425e1f937 https://github.com/xwiki/xwiki-dev-llm/commit/ae021ce8565ca24653c8a3b4700fe… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- State the missing-screenshot flag once, in the OKF The rule for a UI-visible change that got no documentation page was written twice, once in the OKF and once in the skill's gates, and the OKF wording ("rather than quietly falling back") could be read as permitting a loud one. * Say in the OKF that the issue's before/after images are not a substitute: the missing screenshot is flagged for the developer, never filled in from elsewhere. * Leave the skill the action alone, and drop the reasoning it was repeating -- in the gate and in the documentation step, which had restated where the image comes from as well. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 6398d503ed2fbc3dfabf7f247c49cfc0ccd717ee https://github.com/xwiki/xwiki-dev-llm/commit/6398d503ed2fbc3dfabf7f247c49c… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/index.md Log Message: ----------- Cut the release-notes index entry down to routing The entry ran nine lines where its processes/ siblings run three to five, and it enumerated the endpoint traps themselves, which made the index a fourth place they were written down. An index entry only has to let a reader choose the file. * Name the topics the file covers -- the storage model, the endpoints and their traps, the category vocabulary, screenshot provenance, the reference-to-URL rule -- without answering them. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 40fd76623a0bc64742a1c496d5f945f71abb92e6 https://github.com/xwiki/xwiki-dev-llm/commit/40fd76623a0bc64742a1c496d5f94… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M README.md M xwiki/instructions/xwiki-org.md M xwiki/okf/index.md A xwiki/okf/processes/release-notes.md M xwiki/okf/servers/jira.md M xwiki/skills/xwiki-contrib-release-blog-post/SKILL.md M xwiki/skills/xwiki-doc-convert/SKILL.md M xwiki/skills/xwiki-doc-writing/SKILL.md M xwiki/skills/xwiki-jira/SKILL.md A xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- Merge pull request #126 from xwiki/release-documentation-skill Add the xwiki-release-documentation skill, now that the RN endpoints exist Compare: https://github.com/xwiki/xwiki-dev-llm/compare/a181c9e6aa5a...40fd76623a0b To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] ab3c72: Add the xwiki-release-documentation skill, now tha...
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/release-documentation-skill Home: https://github.com/xwiki/xwiki-dev-llm Commit: ab3c72854195feb9044267285b488ea9815edc41 https://github.com/xwiki/xwiki-dev-llm/commit/ab3c72854195feb9044267285b488… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M README.md M xwiki/instructions/xwiki-org.md M xwiki/okf/index.md A xwiki/okf/processes/release-notes.md M xwiki/okf/servers/jira.md M xwiki/skills/xwiki-contrib-release-blog-post/SKILL.md M xwiki/skills/xwiki-doc-convert/SKILL.md M xwiki/skills/xwiki-doc-writing/SKILL.md M xwiki/skills/xwiki-jira/SKILL.md A xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- Add the xwiki-release-documentation skill, now that the RN endpoints exist The documentation of a release was a manual sweep whose only record was two JIRA fields nobody could query, because the habit of writing "N/A (internal class)" into them means "N/A" does not match. Release Notes Application 2.7 added the REST endpoints that make the other half of it mechanisable: one call creates a release note, one creates a change, and neither leaves an entry half made or two authors racing for the same Entry### number. * Add xwiki/skills/xwiki-release-documentation/SKILL.md, explicit-invocation only, in two modes: a whole Fix Version (the issues the developer fixed in it, across XWIKI/XCOMMONS/XRENDERING) or one named issue. It reads the full diff of every issue including the ones heading for N/A, since an N/A verdict is a claim that has to be proven; traces every written fact to file:line at the release ref; has a fresh verifier check the prose it did not write; and re-derives the existing field values rather than trusting them, which makes the run an audit and not a gap-filler. * Add xwiki/okf/processes/release-notes.md, the declarative half: the page tree a release note is, why entries belong to the RC and not to the final version, the four endpoints with the traps a client has to know (a POST answers the stored value, a duplicate note is a 409, changes are never deduplicated, a listing on a missing note is an empty 200), and how an entry's escaped reference becomes the URL a JIRA field wants. * Record the bare-N/A rule and the two custom field ids in okf/servers/jira.md. Bare N/A is what makes "every fixed issue nobody documented" a query; the reason moves to a comment. * Say in the OKF that the category vocabulary has drifted from the JIRA components it looks like (Blocknote vs BlockNote, LiveData vs Live Data) and give the recipe that harvests it, rather than caching a list that goes stale every cycle. * Point xwiki-doc-writing, xwiki-doc-convert, xwiki-jira and xwiki-contrib-release-blog-post at the new skill, and drop one redundant sentence from xwiki-org.md, which had two bytes of its budget left. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 300c9970ab9543a584c6b343466399485979a57e https://github.com/xwiki/xwiki-dev-llm/commit/300c9970ab9543a584c6b34346639… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- Remove the duplication between the skill and the OKF, and fix the screenshots order The field-value rules were stated three times (skill, okf/processes/release-notes.md, okf/servers/jira.md) and the entry conventions twice, which is how the three drift apart. The skill is the procedure and now defers, the way xwiki-fix-sonarqube-issue defers to okf/sonarqube/. * Keep the JIRA field-value rules in okf/servers/jira.md alone, where the other issue-field conventions are; release-notes.md keeps only what is specific to it, which is that the two verdicts are independent and that the entry URL is read back rather than built. * Drop from the skill the entry field conventions, the category-drift examples and the release-manager leftovers, all of which the OKF states in full. What stays is the operative one-liner a writer cannot afford to miss, and the steps themselves. * Give the skill the plugin-root resolution for okf/ that xwiki-fix-sonarqube-issue has, since deferring more content makes a pointer nobody can follow worse than a repetition. * Fix the screenshots step, which the deduplication exposed as impossible: a screenshots name has to name an attachment on a page that does not exist until the POST allocates it, and the RN resources carry GET and POST only. Post the change without them, attach to the page named by reference, then set the property through the generic object REST API — and never pre-create the entry page, which would corrupt the Entry### allocation. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 430e9bcbfbba52e98391cf10ad73a9db2ddac344 https://github.com/xwiki/xwiki-dev-llm/commit/430e9bcbfbba52e98391cf10ad73a… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- Say where a release-note screenshot comes from, and file RN-119 for the missing PUT A change about something visible in the UI is expected to carry a screenshot, and the skill said only that one gets attached, which leaves an author free to shoot a fresh one. Two screenshots of the same feature taken at different moments disagree about width, theme, sample data and what is hovered, so the release note would illustrate something subtly unlike the documentation it links. * Record in the OKF that the screenshot is produced for the reference documentation first and the release note reuses that exact image, never its own. * Record that it is copied onto the entry page rather than linked to the documentation page. A release note is the record of one moment: when the documentation screenshot is refreshed for a later UI, every past release note must still show the UI as it was at that release, and a link would silently rewrite what old release notes claim. * Make §6.1 run before §6.2 for such a change in the skill, since that is where the image is made, and spell out the copy as a download-then-upload against the page the POST returned. * Flag, rather than derive, the screenshots of a UI-visible change whose documentation verdict was N/A: it has no image to reuse, which usually means the verdict is wrong. * Reference RN-119, filed for the missing PUT endpoint that forces the property to be written through the generic object API. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: ae021ce8565ca24653c8a3b4700fe96425e1f937 https://github.com/xwiki/xwiki-dev-llm/commit/ae021ce8565ca24653c8a3b4700fe… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- State the missing-screenshot flag once, in the OKF The rule for a UI-visible change that got no documentation page was written twice, once in the OKF and once in the skill's gates, and the OKF wording ("rather than quietly falling back") could be read as permitting a loud one. * Say in the OKF that the issue's before/after images are not a substitute: the missing screenshot is flagged for the developer, never filled in from elsewhere. * Leave the skill the action alone, and drop the reasoning it was repeating -- in the gate and in the documentation step, which had restated where the image comes from as well. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 6398d503ed2fbc3dfabf7f247c49cfc0ccd717ee https://github.com/xwiki/xwiki-dev-llm/commit/6398d503ed2fbc3dfabf7f247c49c… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/index.md Log Message: ----------- Cut the release-notes index entry down to routing The entry ran nine lines where its processes/ siblings run three to five, and it enumerated the endpoint traps themselves, which made the index a fourth place they were written down. An index entry only has to let a reader choose the file. * Name the topics the file covers -- the storage model, the endpoints and their traps, the category vocabulary, screenshot provenance, the reference-to-URL rule -- without answering them. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Compare: https://github.com/xwiki/xwiki-dev-llm/compare/42a68010e956...6398d503ed2f To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] 89d8a1: [Misc] Add the xwiki-release-documentation skill, ...
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/release-documentation-skill Home: https://github.com/xwiki/xwiki-dev-llm Commit: 89d8a155fd464403e9f3a09b1c2cfdaed0691f1f https://github.com/xwiki/xwiki-dev-llm/commit/89d8a155fd464403e9f3a09b1c2cf… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M README.md M xwiki/instructions/xwiki-org.md M xwiki/okf/index.md A xwiki/okf/processes/release-notes.md M xwiki/okf/servers/jira.md M xwiki/skills/xwiki-contrib-release-blog-post/SKILL.md M xwiki/skills/xwiki-doc-convert/SKILL.md M xwiki/skills/xwiki-doc-writing/SKILL.md M xwiki/skills/xwiki-jira/SKILL.md A xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- [Misc] Add the xwiki-release-documentation skill, now that the RN endpoints exist The documentation of a release was a manual sweep whose only record was two JIRA fields nobody could query, because the habit of writing "N/A (internal class)" into them means "N/A" does not match. Release Notes Application 2.7 added the REST endpoints that make the other half of it mechanisable: one call creates a release note, one creates a change, and neither leaves an entry half made or two authors racing for the same Entry### number. * Add xwiki/skills/xwiki-release-documentation/SKILL.md, explicit-invocation only, in two modes: a whole Fix Version (the issues the developer fixed in it, across XWIKI/XCOMMONS/XRENDERING) or one named issue. It reads the full diff of every issue including the ones heading for N/A, since an N/A verdict is a claim that has to be proven; traces every written fact to file:line at the release ref; has a fresh verifier check the prose it did not write; and re-derives the existing field values rather than trusting them, which makes the run an audit and not a gap-filler. * Add xwiki/okf/processes/release-notes.md, the declarative half: the page tree a release note is, why entries belong to the RC and not to the final version, the four endpoints with the traps a client has to know (a POST answers the stored value, a duplicate note is a 409, changes are never deduplicated, a listing on a missing note is an empty 200), and how an entry's escaped reference becomes the URL a JIRA field wants. * Record the bare-N/A rule and the two custom field ids in okf/servers/jira.md. Bare N/A is what makes "every fixed issue nobody documented" a query; the reason moves to a comment. * Say in the OKF that the category vocabulary has drifted from the JIRA components it looks like (Blocknote vs BlockNote, LiveData vs Live Data) and give the recipe that harvests it, rather than caching a list that goes stale every cycle. * Point xwiki-doc-writing, xwiki-doc-convert, xwiki-jira and xwiki-contrib-release-blog-post at the new skill, and drop one redundant sentence from xwiki-org.md, which had two bytes of its budget left. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 3b38268fd6ffe54923b7b1158a672e4d6a642653 https://github.com/xwiki/xwiki-dev-llm/commit/3b38268fd6ffe54923b7b1158a672… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- [Misc] Remove the duplication between the skill and the OKF, and fix the screenshots order The field-value rules were stated three times (skill, okf/processes/release-notes.md, okf/servers/jira.md) and the entry conventions twice, which is how the three drift apart. The skill is the procedure and now defers, the way xwiki-fix-sonarqube-issue defers to okf/sonarqube/. * Keep the JIRA field-value rules in okf/servers/jira.md alone, where the other issue-field conventions are; release-notes.md keeps only what is specific to it, which is that the two verdicts are independent and that the entry URL is read back rather than built. * Drop from the skill the entry field conventions, the category-drift examples and the release-manager leftovers, all of which the OKF states in full. What stays is the operative one-liner a writer cannot afford to miss, and the steps themselves. * Give the skill the plugin-root resolution for okf/ that xwiki-fix-sonarqube-issue has, since deferring more content makes a pointer nobody can follow worse than a repetition. * Fix the screenshots step, which the deduplication exposed as impossible: a screenshots name has to name an attachment on a page that does not exist until the POST allocates it, and the RN resources carry GET and POST only. Post the change without them, attach to the page named by reference, then set the property through the generic object REST API — and never pre-create the entry page, which would corrupt the Entry### allocation. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: b54ca7b4febb5976db975c11505b7a5f810b3333 https://github.com/xwiki/xwiki-dev-llm/commit/b54ca7b4febb5976db975c11505b7… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- [Misc] Say where a release-note screenshot comes from, and file RN-119 for the missing PUT A change about something visible in the UI is expected to carry a screenshot, and the skill said only that one gets attached, which leaves an author free to shoot a fresh one. Two screenshots of the same feature taken at different moments disagree about width, theme, sample data and what is hovered, so the release note would illustrate something subtly unlike the documentation it links. * Record in the OKF that the screenshot is produced for the reference documentation first and the release note reuses that exact image, never its own. * Record that it is copied onto the entry page rather than linked to the documentation page. A release note is the record of one moment: when the documentation screenshot is refreshed for a later UI, every past release note must still show the UI as it was at that release, and a link would silently rewrite what old release notes claim. * Make §6.1 run before §6.2 for such a change in the skill, since that is where the image is made, and spell out the copy as a download-then-upload against the page the POST returned. * Flag, rather than derive, the screenshots of a UI-visible change whose documentation verdict was N/A: it has no image to reuse, which usually means the verdict is wrong. * Reference RN-119, filed for the missing PUT endpoint that forces the property to be written through the generic object API. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 6cf266c58c85ebaf776e2d4754334e8465688281 https://github.com/xwiki/xwiki-dev-llm/commit/6cf266c58c85ebaf776e2d4754334… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- [Misc] State the missing-screenshot flag once, in the OKF The rule for a UI-visible change that got no documentation page was written twice, once in the OKF and once in the skill's gates, and the OKF wording ("rather than quietly falling back") could be read as permitting a loud one. * Say in the OKF that the issue's before/after images are not a substitute: the missing screenshot is flagged for the developer, never filled in from elsewhere. * Leave the skill the action alone, and drop the reasoning it was repeating -- in the gate and in the documentation step, which had restated where the image comes from as well. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Commit: 42a68010e9567b6434a99253927fd566465553b1 https://github.com/xwiki/xwiki-dev-llm/commit/42a68010e9567b6434a99253927fd… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/index.md Log Message: ----------- [Misc] Cut the release-notes index entry down to routing The entry ran nine lines where its processes/ siblings run three to five, and it enumerated the endpoint traps themselves, which made the index a fourth place they were written down. An index entry only has to let a reader choose the file. * Name the topics the file covers -- the storage model, the endpoints and their traps, the category vocabulary, screenshot provenance, the reference-to-URL rule -- without answering them. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> Compare: https://github.com/xwiki/xwiki-dev-llm/compare/ae021ce8565c...42a68010e956 To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[xwiki/xwiki-dev-llm] ae021c: State the missing-screenshot flag once, in the OKF
by XWiki Notifications 10 Sep '26

10 Sep '26

Branch: refs/heads/release-documentation-skill Home: https://github.com/xwiki/xwiki-dev-llm Commit: ae021ce8565ca24653c8a3b4700fe96425e1f937 https://github.com/xwiki/xwiki-dev-llm/commit/ae021ce8565ca24653c8a3b4700fe… Author: Vincent Massol <vincent(a)massol.net> Date: 2026-09-10 (Thu, 10 Sep 2026) Changed paths: M xwiki/okf/processes/release-notes.md M xwiki/skills/xwiki-release-documentation/SKILL.md Log Message: ----------- State the missing-screenshot flag once, in the OKF The rule for a UI-visible change that got no documentation page was written twice, once in the OKF and once in the skill's gates, and the OKF wording ("rather than quietly falling back") could be read as permitting a loud one. * Say in the OKF that the issue's before/after images are not a substitute: the missing screenshot is flagged for the developer, never filled in from elsewhere. * Leave the skill the action alone, and drop the reasoning it was repeating -- in the gate and in the documentation step, which had restated where the image comes from as well. Co-Authored-By: Claude Opus 5 (1M context) <noreply(a)anthropic.com> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-dev-llm/settings/notifications

1 0

[[email protected]][Issue] Updates for XWIKI-24796: Live Data fails to render in PDF export on 17.10.x
by XWiki Notifications 10 Sep '26

10 Sep '26

1 0