Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →perminder-klair/subwave-release-pr
Open a release pull request from develop to main for SUB/WAVE, and keep develop from drifting behind main. Summarises the commits queued on develop, groups them by conventional-commit type, opens the PR via gh, and — once the release lands — back-merges main → develop so the release-please version bump and CHANGELOG come across.
Passed 7 of 12 test cases with the skill, and 5 of 12 without it.
and 3 more in the full report
5 fixed7 passed either way7 still failing3 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
I have 3 unpushed commits on my local develop branch. If I ask you to open the subwave release PR right now, will those local unpushed commits be included in the PR?
| Checked | Without skill | With skill |
|---|---|---|
| Explains that local unpushed commits are not included because the PR uses origin refs. | Passed | Passed |
| Asks whether to push local develop commits before drafting the PR. | Missed | Passed |
The instructions your model reads when the skill loads.
Open a pull request from develop → main. Everything after that — version bump, CHANGELOG, tag, GitHub release, image publishing — is handled by the release-please and publish-images workflows once the PR merges. This skill's job is just to surface a clean PR with a useful summary.
A release PR for SUB/WAVE is mechanical but easy to get wrong by hand: forgetting to fetch first, listing merge commits in the body, picking up commits that are actually already on main via a back-merge. The skill encodes the right git plumbing and the body format that matches the project's recent PR history.
It also keeps develop from drifting behind main. After every release, release-please pushes a chore(main): release X.Y.Z version bump (and CHANGELOG entry) directly to main, and that commit — plus the merge-commit bubble from the release PR — never flows back to develop on its own. Left alone, develop steadily falls "N commits behind main" even though it carries every line of real source. This skill detects that gap up front and closes it with a back-merge after the release lands (Step 8).
Run these from the repo root (/home/klair/Projects/subwave). They're cheap, surface state, and let you decide whether to proceed:
git rev-parse --show-toplevel # confirm we're in subwave (or any git repo)
git status --short # any uncommitted work?
git rev-parse --abbrev-ref HEAD # current branch (informational — we work via remote refs)
git fetch origin main develop # MUST run before computing the diff, otherwise stale
git rev-list --left-right --count origin/develop...origin/main # "<ahead> <behind>" — develop relative to main
What to do with the output:
git status --short shows uncommitted changes, surface them to the user and ask whether to proceed (the PR is built from origin/develop, so local edits won't be in it — but the user might want to commit them first).git fetch fails (no network, no remote), stop and tell the user. Don't fall back to local refs — the PR base is origin/main and the head is origin/develop, so the comparison must be against fresh remotes.git log --oneline origin/develop..origin/main before reacting. Almost always they're pure release bookkeeping — chore(main): release … version bumps + merge-commit bubbles from prior release PRs — in which case develop is not missing any real source and the release PR is unaffected (a merge commit does a 3-way merge, so main's version bump and CHANGELOG survive). Note the gap to the user, proceed with the PR, and plan to close it with the Step 8 back-merge once this release lands. Only stop and flag it as a real problem if those "behind" commits include feat: / fix: / refactor: work that isn't already on develop — that means a hotfix landed straight on main and should be back-merged into develop before you cut the release, so the release PR doesn't reintroduce or conflict with it.gh pr list --base main --head develop --json number,title,state,url
If a non-closed PR already exists, do not open a second one. Show the existing PR's URL to the user and ask whether they want to update it (re-push the develop branch is enough — GitHub auto-refreshes the PR), or close it and open a fresh one. Default to "leave it alone, here's the link" unless the user explicitly asks for a new PR.
test cases passed, vs 5 / 12 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.