docs(release-skill): the tag push publishes the release; step 3 edits it - #898
Open
ako wants to merge 1 commit into
Open
docs(release-skill): the tag push publishes the release; step 3 edits it#898ako wants to merge 1 commit into
ako wants to merge 1 commit into
Conversation
The skill's step 3 says `gh release create`, but .github/workflows/release.yml fires on any `v*` tag and calls softprops/action-gh-release with generate_release_notes: true. By the time you reach step 3 the release is already public, with the six binaries attached and a body that is the flat PR dump step 3 exists to prevent — so the documented command cannot succeed, and the skill never says the release has already happened. Found while cutting v0.18.0: the tag push published the release, and the curated body had to go on with `gh release edit` after the fact. v0.17.0's published body is the curated section, so this is what the maintainer already does; only the skill was out of date. - Step 2 states plainly that pushing the tag publishes the release, and warns off the two wrong reactions: creating the release first, or deleting and recreating it (which drops the uploaded assets). - Step 3 becomes "replace the generated body", using `gh release edit`. The awk/generate-notes block that builds $BODY is unchanged. - Adds the workflow-failed fallback (`gh release create` with the same body) and an asset check, and splits the checklist line into the two things that now happen separately. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
.claude/skills/release.mdstep 3 says to create the GitHub release withgh release create. It cannot work:.github/workflows/release.ymltriggers on anyv*tag and callssoftprops/action-gh-releasewithgenerate_release_notes: true, so pushing the tag in step 2 already publishes the release — public, six binaries attached, and a body that is exactly the flat PR dump step 3 exists to prevent.The skill never mentions that the release has already happened, which leaves two tempting wrong moves: racing the workflow, or deleting and recreating the release (dropping the assets it uploaded).
Found while cutting v0.18.0. The tag push published the release, and the curated body went on afterwards with
gh release edit.v0.17.0's published body is the curated CHANGELOG section, so this is already what happens in practice — only the skill was out of date.Change
gh release edit. Theawk+generate-notesblock that assembles$BODYis unchanged.gh release createwith the same body), an asset check, and splits the checklist line into the two things that now happen separately.Docs only — no code, no behaviour change.
Validation
Verified against the live v0.18.0 release:
gh release edit v0.18.0 --notes-file …replaced the generated body and left the tag and all six assets untouched.