| name | update-release-metadata |
| description | Prepares a GitHub PR to update Livingdocs release metadata on announcement day. Use this skill when the user mentions updating release metadata, announcement day, a release going live, or wants to prepare the metadata PR for a new release (e.g. "release-2026-05 is being announced today", "update the release metadata", "prepare announcement day PR"). This skill handles the full git workflow: branch creation, file edits, commit, push, and PR creation. |
Update Release Metadata
On announcement day, the release state machine needs to advance: a new release moves from upcoming to current, the previous current becomes maintained, and the oldest maintained becomes legacy. This skill handles all the file edits and git workflow.
Step 1: Identify the release
If the user hasn't specified a release handle, ask them: "Which release are we announcing? (e.g. release-2026-05)"
Then read data/releases.json from the repo root and identify the three releases that will change:
- New release (becoming current): The named entry (not the
main key) matching the user's release handle. It should have upcoming: true.
- Previous current (becoming just maintained): The entry with
current: true.
- Oldest maintained (becoming legacy): Among entries where
maintained: true, current: false, and legacy: false, pick the one with the lowest sortId.
Confirm with the user before making any changes:
"I'll update these three releases:
<new-release>: upcoming → current<prev-current>: current → maintained (no longer current)<oldest-maintained>: maintained → legacy
Looks right?"
Step 2: Create the branch
Run from the documentation repo root:
git checkout main
git pull origin main
git checkout -b update-release-metadata/<release-handle>
Step 3: Apply the metadata changes
Four files need updating. Make all changes precisely — only modify the metadata fields listed below, nothing else.
New release markdown file
File: content/operations/releases/<new-release>.md
In the YAML frontmatter at the top:
| Field | Before | After |
|---|
excludeFromSearch | true | false |
upcoming | true | false |
current | false | true |
maintained | false | true |
The header: block will look like this after the change:
header:
upcoming: false
legacy: false
current: true
maintained: true
Previous current release markdown file
File: content/operations/releases/<prev-current>.md
| Field | Before | After |
|---|
current | true | false |
Only this one field changes. maintained stays true.
Oldest maintained release markdown file
File: content/operations/releases/<oldest-maintained>.md
| Field | Before | After |
|---|
maintained | true | false |
legacy | false | true |
data/releases.json
Apply the same logical changes for all three releases in their respective JSON objects (matched by key):
New release entry:
"upcoming": false,
"current": true,
"maintained": true,
Previous current entry:
"current": false,
(maintained stays true)
Oldest maintained entry:
"maintained": false,
"legacy": true,
Step 4: Commit
Stage only the four files you changed:
git add content/operations/releases/<new-release>.md
git add content/operations/releases/<prev-current>.md
git add content/operations/releases/<oldest-maintained>.md
git add data/releases.json
git commit -m "fix(<release-handle>): add new release metadata for release announcement day"
The fix(<release-handle>): semantic prefix fix is required — without it, no deployment is triggered. The release-handle is only needed for better readability.
Step 5: Push and create the PR
git push -u origin update-release-metadata/<release-handle>
Then create the PR (use gh pr create or the GitHub MCP):
- Title:
<release-handle>: Update release metadata
- Base branch:
main
- Body:
### Motivation
Update release metadata for new <release-handle> and old ones accordingly.
*Note: Only merge on announcement day*
Return the PR URL to the user.
