release-finalizer
Skill326 starsChanged 8 months agoMITView on GitHub
Merges a release PR, associates it with resolved issues, replies to issue reporters, and closes issues. Use after PR review is complete and ready for merge. Closes the release cycle.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- Fu-Jie/openwebui-extensionsword for word, first seen Oct 8, 2026
Other versions1 project uses a version of this.
Word for word · 1
- Fu-Jie/openwebui-extensions★ 326100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- community-announcerSkill
- doc-mirror-syncSkill
- gh-discussion-replierSkill
- gh-issue-replierSkill
- gh-issue-schedulerSkill
- i18n-validatorSkill
- playwright-openwebuiSkill
- plugin-scaffolderSkill
- pr-reviewerSkill
- pr-submitterSkill
- publish-no-version-bumpSkill
- release-prepSkill
- source-code-analyzerSkill
- version-bumperSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 10 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 15
All status checks have passed (CI green)
- Distinctive: line 16
All review feedback has been addressed
- Distinctive: line 25
Verify that the PR is ready:
- Distinctive: line 36
If any check fails, do NOT merge.
- Distinctive: line 46
Look for patterns like:
- Distinctive: line 50
Manual input: If issue links are not in the PR, ask the user which issue(s) this PR resolves.
- Very specific: line 64
Recommendation for release PRs: Use --squash to create a single clean commit.
- Very specific: line 66
If user doesn't specify, default to --squash.
- Very specific: line 70
If using --squash, craft a single comprehensive commit message:
- Distinctive: line 144
If the merge revealed any final tweaks to release notes:
- Distinctive: line 151
If needed, create a follow-up PR with doc polish (do NOT force-push the merged commit).
- Very specific: line 198
Verify the Closes #XX keyword is in the final commit message (use git log to check)
- Distinctive: line 199
Ensure the commit is on the main branch
- Distinctive: line 208
Only recommended if the PR was manually reverted or deemed invalid
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Release Finalizer
Overview
This skill completes the final step of the release cycle: merging the release PR to main, replying to all related issues with solutions, and automatically closing them using GitHub's issue linking mechanism.
Prerequisites
- The PR is in
OPENstate and ready to merge - All status checks have passed (CI green)
- All review feedback has been addressed
- The PR relates to one or more GitHub issues (either in PR description or through commits)
Workflow
Step 1 — Pre-Merge Verification
Verify that the PR is ready:
PAGER=cat GH_PAGER=cat gh pr view <PR-NUMBER> --json state,statusCheckRollup,reviewDecisionChecklist:
- ✅
stateisOPEN - ✅
statusCheckRollupall haveconclusion: SUCCESS - ✅
reviewDecisionisAPPROVEDor empty (no blocking reviews)
If any check fails, do NOT merge. Report the issue to the user.
Step 2 — Identify Related Issues
Issues can be linked to a PR in multiple ways. Check the PR description and commit messages for keywords:
PAGER=cat GH_PAGER=cat gh pr view <PR-NUMBER> --json body,commitsLook for patterns like:
Closes #XX,Fixes #XX,Resolves #XX(in description or commit bodies)#XXmentioned as "related to" or "addresses"
Manual input: If issue links are not in the PR, ask the user which issue(s) this PR resolves.
Extract all issue numbers into a list: [#48, #52, ...]
Step 3 — Select Merge Strategy
Offer the user three options:
| Strategy | Git Behavior | Use Case |
| Squash | All commits squashed into one commit on main | Clean history, recommended for release PRs |
| Rebase | Linear history, no merge commit | Preserve commit granularity |
| Merge | Merge commit created | Preserve full PR context |
Recommendation for release PRs: Use --squash to create a single clean commit.
If user doesn't specify, default to --squash.
Step 4 — Prepare Merge Commit Message
If using --squash, craft a single comprehensive commit message:
Format (Conventional Commits + Github linking):
type(scope): description
- Bullet point 1
- Bullet point 2
Closes #48
Closes #52The Closes #XX keyword tells GitHub to automatically close those issues when the commit lands on main.
Example:
feat(pipes,filters): release Copilot SDK Pipe v0.8.0 and Files Filter v0.1.3
- Implement P1~P4 conditional tool filtering system
- Fix file publishing reliability across all storage backends
- Add strict file URL validation
- Update bilingual documentation
Closes #48Step 5 — Execute Merge
gh pr merge <PR-NUMBER> \
--squash \
--delete-branch \
-m "type(scope): description" \
-b "- Bullet 1\n- Bullet 2\n\nCloses #48"Key flags:
--squash: Squash commits (recommended for releases)--delete-branch: Delete the feature branch after merge-m: Commit subject-b: Commit body (supports\nfor newlines)
Confirm the merge is successful; GitHub will automatically close related issues with Closes #XX keyword.
Step 6 — Verify Auto-Close
GitHub automatically closes issues when a commit with Closes #XX lands on the default branch (main).
To verify:
PAGER=cat GH_PAGER=cat gh issue view <ISSUE-NUMBER> --json stateShould show state: CLOSED.
Step 7 — Post Closing Message (Optional but Recommended)
For better UX, manually post a summary comment to each issue before it auto-closes (since auto-close happens silently):
gh issue comment <ISSUE-NUMBER> --body "
This has been fixed in PR #<PR-NUMBER>, which is now merged to main.
**Solution Summary:**
- <Key fix 1>
- <Key fix 2>
The fix will be available in the next plugin release. Thank you for reporting! ⭐
"Step 8 — (Optional) Regenerate Release Notes
If the merge revealed any final tweaks to release notes:
# Re-export release notes from merged commit
git log --oneline -1 <merged-commit-sha>If needed, create a follow-up PR with doc polish (do NOT force-push the merged commit).
Merge Strategy Decision Tree
Is this a patch/hotfix release?
├─ YES → Use --squash
└─ NO → Multi-feature release?
├─ YES → Use --squash (cleaner history)
└─ NO → Preserve detail?
├─ YES → Use --rebase
└─ NO → Use --merge (preserve PR context)Issue Auto-Close Keywords
These keywords in commit/PR messages will auto-close issues when merged to main:
Closes #XXFixes #XXResolves #XXclose #XX(case-insensitive)fix #XXresolve #XX
Important: The keyword must be on the final commit that lands on main. For squash merges, it must be in the squash commit message body.
Anti-Patterns to Avoid
- ❌ Do NOT merge if any status checks are PENDING or FAILED
- ❌ Do NOT merge if there are blocking reviews (reviewDecision:
CHANGES_REQUESTED) - ❌ Do NOT merge without verifying the Conventional Commits format in the merge message
- ❌ Do NOT merge without including
Closes #XXkeywords for all related issues - ❌ Do NOT assume issues will auto-close silently — post a courtesy comment first
- ❌ Do NOT delete the branch if it might be needed for cherry-pick or hotfixes later
Troubleshooting
Issue did not auto-close after merge
- Verify the
Closes #XXkeyword is in the final commit message (usegit logto check) - Ensure the commit is on the
mainbranch - GitHub sometimes takes a few seconds to process; refresh the issue page
Multiple issues to close
- List all in separate
Closes #XXlines in the commit body - Each one will be independently auto-closed
Want to close issue without merge?
- Use
gh issue close <ISSUE-NUMBER>manually - Only recommended if the PR was manually reverted or deemed invalid
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

