Branch: refs/heads/release-documentation-skill Home: https://github.com/xwiki/xwiki-dev-llm Commit: 89d8a155fd464403e9f3a09b1c2cfdaed0691f1f https://github.com/xwiki/xwiki-dev-llm/commit/89d8a155fd464403e9f3a09b1c2cfd... 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: ----------- [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) <[email protected]> Commit: 3b38268fd6ffe54923b7b1158a672e4d6a642653 https://github.com/xwiki/xwiki-dev-llm/commit/3b38268fd6ffe54923b7b1158a672e... 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: ----------- [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) <[email protected]> Commit: b54ca7b4febb5976db975c11505b7a5f810b3333 https://github.com/xwiki/xwiki-dev-llm/commit/b54ca7b4febb5976db975c11505b7a... 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: ----------- [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) <[email protected]> Commit: 6cf266c58c85ebaf776e2d4754334e8465688281 https://github.com/xwiki/xwiki-dev-llm/commit/6cf266c58c85ebaf776e2d4754334e... 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: ----------- [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) <[email protected]> Commit: 42a68010e9567b6434a99253927fd566465553b1 https://github.com/xwiki/xwiki-dev-llm/commit/42a68010e9567b6434a99253927fd5... Author: Vincent Massol <[email protected]> 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) <[email protected]> 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