Cutting a release

Skill gustavo-meilus/aiboarding/.claude/skills/cutting-a-release

Keep AGENTS.md alive: generate, compress, audit, and update AI-agent onboarding for Claude Code, Codex, Copilot, Cursor, and OpenCode.

Install

npx -y skills add gustavo-meilus/aiboarding --skill cutting-a-release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Cut an aiboarding version release (vX.Y.Z) - verify the single version target agrees, draft matching CHANGELOG + RELEASE-NOTES entries, commit to main, then create the GitHub release + tag and verify. Use when the user asks to cut/ship/publish a release, tag a version, do release work, or write release notes for aiboarding.

SKILL.md

3.2 KB, as published. Nobody here has run it

Cutting an aiboarding Release

Cut a version release after the feature work is merged into main. Full step detail + gotchas live in RUNBOOK.md - read it before acting.

Hard constraints (read first)

main is NOT branch-protected. Direct git push origin main works; no PR or --admin dance required. (Confirm with the user if they prefer a PR anyway.)
No CI. No GitHub Actions gate - verification is rg/Read assertions + python3 -c "import json; json.load(...)". Nothing waits on green checks.
One version target. Only .claude-plugin/plugin.json (version) carries the version. marketplace.json has NO per-plugin version field - do not add one. There is no package.json / .version-bump.json / .cursor-plugin / CLAUDE.md version.
JSON must be BOM-free. Never Set-Content -Encoding UTF8 for JSON. Use the Edit tool or python3 writes (encoding="utf-8").
Tag ↔ changelog convention (stated in CHANGELOG.md header): every tag vX.Y.Z MUST have a matching ## X.Y.Z CHANGELOG entry and a ## vX.Y.Z RELEASE-NOTES entry before gh release create.
gh CLI in Bash tool: never --body @'...'@ (PowerShell here-string, fails). Write the body to a temp .md, use --body-file, then rm it. Keep temp files out of commits.
Title form: vX.Y.Z - <Title Case Feature Name> (matches existing releases).

Workflow

Preflight - git fetch origin; confirm origin/main has the feature merge; verify plugin.json version equals the intended vX.Y.Z; check tag/release naming convention.
Sync local main - git checkout main && git pull --ff-only origin main.
Bump version if needed - if the feature work did not already bump plugin.json, do it now (Edit tool, BOM-free).
Draft doc entries - add ## X.Y.Z to CHANGELOG.md (with trailing --- separator) and a <release_entry> to RELEASE-NOTES.md, mirroring the previous entry's format exactly; extend the <overview> milestone sentence and the Roadmap. Source bullets from real changes; do not invent.
Commit to main - git add the changed files, commit, git push origin main. (No PR needed - main is open.)
Create release + tag - extract the new CHANGELOG section as the release body, append the install line, gh release create vX.Y.Z --target main --title "vX.Y.Z - <Title>" --notes-file <tmp>.
Verify - tag commit == origin/main; release not draft/prerelease; it shows as Latest.

Gotchas checklist

Bumped plugin.json version only - did NOT add a version field to marketplace.json.
plugin.json version == intended vX.Y.Z before tagging.
CHANGELOG (## X.Y.Z + ---) and RELEASE-NOTES (<release_entry> + overview + roadmap) entries exist before gh release create.
Used --body-file for all gh bodies (never @'...'@).
JSON edits BOM-free.
Temp files cleaned up, kept out of commits.