Branch: refs/heads/release-documentation-skill Home: https://github.com/xwiki/xwiki-dev-llm Commit: ab3c72854195feb9044267285b488ea9815edc41 https://github.com/xwiki/xwiki-dev-llm/commit/ab3c72854195feb9044267285b488e... Author: Vincent Massol <[email protected]> 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) <[email protected]> Commit: 300c9970ab9543a584c6b343466399485979a57e https://github.com/xwiki/xwiki-dev-llm/commit/300c9970ab9543a584c6b343466399... Author: Vincent Massol <[email protected]> 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) <[email protected]> Commit: 430e9bcbfbba52e98391cf10ad73a9db2ddac344 https://github.com/xwiki/xwiki-dev-llm/commit/430e9bcbfbba52e98391cf10ad73a9... Author: Vincent Massol <[email protected]> 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) <[email protected]> Commit: ae021ce8565ca24653c8a3b4700fe96425e1f937 https://github.com/xwiki/xwiki-dev-llm/commit/ae021ce8565ca24653c8a3b4700fe9... Author: Vincent Massol <[email protected]> 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) <[email protected]> Commit: 6398d503ed2fbc3dfabf7f247c49cfc0ccd717ee https://github.com/xwiki/xwiki-dev-llm/commit/6398d503ed2fbc3dfabf7f247c49cf... Author: Vincent Massol <[email protected]> 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) <[email protected]> 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