Release-prep skill based on princeton-cdh software release checklist - #7

[rlskoeser]

Changes in this PR

• New release-prep skill, based on our existing software release checklist

Notes

• Created this skill in web chat with claude, and iterated on it some; I used a preliminary version of the skill to create a release branch and PR Release 0.6 corppa#296
• Note that the skill requires you to have github cli tool installed - not sure where this should be documented
• I've revised it since then but wasn't easy to test it fully since I had already created my release branch
• This replaces the draft PR I originally created on our .github repo Release-prep skill based on princeton-cdh software release checklist .github#7
• Share your thoughts on how/whether the skill should interact with the issue checklist approach we've been using. Should this replace the old issue checklist approach? I've added but not tested a step to comment on the issue reporting what was done, status, and next steps (there's no gh cli or api endpoint for checklist items)

Reviewer Checklist

• Read through the skills and comment/ask questions on anything that doesn't make sense, seems odd/dangerous/wrong, is too verbose, etc. FYI, probably easier to read the rendered markdown version first, then comment on the PR.
• If you can, try out this skill locally the next time you prep a release so we can test & refine it

[tanhaow]

I thoroughly enjoyed the experience of preparing a release using this agentic skill. Based on my observations and experiences, I have a few suggestions:

• Add the rc postfix to the version number.
• Open the PR as a draft PR instead of a regular PR.
• Ensure that the changelog references previous entries to maintain consistency in language and style.
• Keep the “closes #xxx” section to automatically connect the PR to the issue on Zenhub.

Thank you once again for spending time writing this skill up. It’s very convenient and helpful!

[tanhaow]

Just found that we might want to include one more task in the "Needs your judgment" checklist section that is to decide which PRs by dependabot to pull into the new release (if there are any).

[laurejt]

My experiences using the skill with a local model (gemma4) for viapy (minor changes since the last release):

• Overall: Not sure how well this skill will work for local models, in the end all this did was bump the version and make/push a release branch
• It failed to run the unit tests because it didn't figure out the need to use uv run. Seems like it might be worth an elaboration on environment assumptions, since the skill suggests pytest is installed in the active environment instead of say via uv run
• Only change in release branch was to bump the version
• No changelog edits. Partial failure due to not having authenticated gh, but clearly did not add anything based on the commit log.
• Got an odd local settings flagged message: "The detected sample file path was outside the current repository's context, preventing a comparison against local settings." I'm guessing this has something to do with viapy's django unique/optional django setup (only sample setting file is for unit tests)
• It did check the uv.lock, so that's something
• Says a PR was created, when it hasn't been (but the release branch was pushed)... seems like the TUI output might be the text intended for the PR message
• The commit make no mention of automation, which seems important since these commits will end up in the main commit history

Question: What is (or should be) the expected behavior of the skill if a pre-commit hook fails? It seems plausible that this might occur when drafting the changelog.

Some suggestions:

• Add step for reviewing code documentation? It's in the checklist but perhaps it's out-of-scope for the skill
• Add step for reviewing the commit log? It's in the checklist and it seems plausible that the skill could flag commits that should be combined or whose logs need some editing.
• It seems like there should be some accompanying human-centered documentation that provides information about the skill, particularly the general expectation for a config file.