release-manager
Skill54 starsChanged 21 days agoApache-2.0View on GitHub
Automated release management skill for uiautomator2-mcp-server. Evaluates codebase status, runs checks, updates documentation, and manages the complete release workflow.
- Commits and pushes
26 other projects use a version of this.
Adopted by
Most recently taken up by
- sunholo-data/ailangtheir own version, first seen Nov 6, 2026
- hongphuc5497/skillstheir own version, first seen Nov 1, 2026
- thefrederiksen/devthrottletheir own version, first seen Nov 1, 2026
- fritzprix/libr-agenttheir own version, first seen Oct 26, 2026
- LazyIsEfficient/agentic-ostheir own version, first seen Oct 22, 2026
- pawellach/pm-ai-promptstheir own version, first seen Oct 20, 2026
Used with
Projects with it also use qa-agent, dependency-auditor and 4 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
arnaudgelasSkillqa-agent
Answer questions from the vault, then file durable insights back into the knowledge base.
Also in 3 projects that use this
mar-antayaSkilldependency-auditor
Dependency Auditor
Also in 3 projects that use this
ArogyaReddySkillchangelog-generator
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
Also in 3 projects that use this
MicrosoftSkillplaywright-cli
Automate browser interactions, test web pages and work with Playwright tests.
Also in 3 projects that use this
SentrySkillskill-creator
Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, writing, registration, and verification.
Also in 4 projects that use this
GoogleSkillgrill-me
A relentless interview to sharpen a plan or design.
Also in 3 projects that use this
Other versions26 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 26
- voidzero-dev/vite-plus★ 6.6ksame name
- poingstudios/godot-admob-plugin★ 648same name
- thefrederiksen/cc-director★ 110same name
- thefrederiksen/devthrottle★ 110same name
- LongNgn204/local-coding-agent★ 56same name
- Agile-V/agile_v_skills★ 54same name
- sunholo-data/ailang★ 38same name
- felvieira/claude-skills-fv★ 27same name
- sampleXbro/agentsmesh★ 27same name
- LazyIsEfficient/agentic-os★ 17same name
16 more not listed
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 repository4 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- android-ui-testSkill
- douyin-searchSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. 0 are common, 15 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 24 edited versions we read keep these.
15
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 48
Ensure code quality and documentation completeness before release
- Distinctive: line 66
Check version numbers and changelog entries
- Distinctive: line 67
CRITICAL: Verify all untracked files are handled (committed or .gitignore'd)
- Distinctive: line 68
Verify working directory is clean (no uncommitted changes)
- Distinctive: line 74
Run comprehensive test suite
- Distinctive: line 77
Check for breaking changes and migration guides
- Distinctive: line 82
Update version numbers if needed
- Distinctive: line 84
Update README and other documentation
- Distinctive: line 94
VERIFY: all changes are committed (check git status - clean working directory)
- Distinctive: line 110
Verify PyPI package publication
- Distinctive: line 153
Tag created on wrong branch: Delete and recreate on correct branch
- Distinctive: line 154
Uncommitted changes discovered: Commit and restart tag process
- Distinctive: line 165
Commit reversion with explanatory messages
- Distinctive: line 199
Document emergency release rationale
- Distinctive: line 200
Follow up with proper post-release validation
“Common” is measured: kept by at least 6 in 10 of the 24 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Release Manager Skill
⚠️ CRITICAL: Git Tag Timing & Branch Management
MOST IMPORTANT: Git tagging MUST happen at the EXACT LAST MOMENT before pushing to remote, on the main/master branch ONLY.
The Absolute Rule
Git tag creation is the FINAL step before pushing - nothing comes after it except git push.
Tag Timing Rules
❌ WRONG: Tag during development/testing phase ❌ WRONG: Tag before final validation ❌ WRONG: Tag before merging to main/master ❌ WRONG: Tag on develop branch ❌ WRONG: Tag → then discover uncommitted files ❌ WRONG: Tag → then realize tests need to run ✅ CORRECT: All work complete → Merged to main/master → Tag (FINAL STEP) → Push
Branch Management Rules
- Development happens on:
developbranch - Release commits created on:
developbranch - Merge direction:
develop→main(ormaster) - Tag location:
main(ormaster) branch ONLY - Push order: Push main branch, then push tag
Why this matters:
- Premature tagging creates broken releases where the tag points to incomplete/untested code
- Tags on wrong branches cause version confusion and deployment issues
- Proper branch isolation ensures clean release history
- Tagging as the final step guarantees the tagged commit is exactly what gets published
Goals
- Automate the complete release workflow from evaluation to publication
- Ensure code quality and documentation completeness before release
- Provide interactive release management with human oversight
- Support both standard and emergency release scenarios
- CRITICALLY: Enforce proper git tag timing to prevent broken releases
Prerequisites
- Git repository with proper remote configuration
- Python development environment with required tools installed
- GitHub account with repository access permissions
- Proper version control setup (main/develop branches)
- Pre-commit hooks configured and working
Release Workflow Phases
Phase 1: Codebase Evaluation
- Assess current Git status and branch position
- Review recent commits and changes since last release
- Check version numbers and changelog entries
- CRITICAL: Verify all untracked files are handled (committed or .gitignore'd)
- Verify working directory is clean (no uncommitted changes)
- Evaluate overall project health and readiness
⚠️ NO git operations in this phase
Phase 2: Quality Assurance
- Run comprehensive test suite
- Execute pre-commit checks and linting
- Validate documentation completeness
- Check for breaking changes and migration guides
⚠️ NO git operations in this phase
Phase 3: Preparation
- Update version numbers if needed
- Finalize CHANGELOG entries
- Update README and other documentation
- Prepare release notes and announcements
⚠️ Changes made but NOT tagged yet
Phase 4: Execution (Critical Timing Phase)
DEVELOPMENT BRANCH: develop RELEASE BRANCH: main (or master)
- VERIFY all changes are committed (check
git status- clean working directory) - CREATE FINAL RELEASE COMMIT on develop branch
- SWITCH to main/master branch:
git checkout main(ormaster) - MERGE develop to main/master:
git merge develop - VERIFY merge is clean (fast-forward preferred, or clean merge)
- VERIFY on correct branch (main/master)
- VERIFY working directory is still clean
- CREATE GIT TAG on main/master ← THE FINAL STEP
- This is the LAST action before pushing
- NOTHING should happen after tagging except push
- PUSH main/master branch to remote
- PUSH tag to remote
- Monitor CI/CD pipeline status
Phase 5: Verification
- Confirm successful GitHub release creation
- Verify PyPI package publication
- Check documentation deployment
- Send release notifications
Critical Git Tag Timing & Branch Rules
✅ CORRECT SEQUENCE:
1. Make all necessary code/documentation changes (on develop)
2. Verify git status - ensure ALL files are committed
3. Run complete tests and validation
4. Get final approval for release
5. Create final release commit on develop
6. Switch to main/master branch
7. Merge develop to main/master
8. Verify on correct branch (main/master)
9. Verify working directory is clean
10. CREATE GIT TAG on main/master (FINAL STEP - NOTHING AFTER THIS)
11. Push everything to remote❌ INCORRECT SEQUENCES TO AVOID:
❌ Test → Tag → Fix issues → Push (Tag points to broken code)
❌ Develop → Tag → Test → Push (Tag created too early)
❌ Tag → Test → Fix → Push (Backwards workflow)
❌ Tag → Find uncommitted files → Commit → Tag wrong commit (Version confusion)
❌ Tag → Realize need to merge → Merge → Tag wrong commit (Wrong branch)
❌ Merge → Push → Remember to tag → Tag → Push tag (Tag missed the release)Interactive Decision Points
The skill will pause at key decision points to allow human review:
- ✅ Pre-flight Check: Confirm release readiness assessment
- ✅ Quality Gate: Approve test results and code quality
- ✅ Final Approval: CRITICAL - Authorize git tag creation
- ✅ Post-release Verification: Confirm successful deployment
Error Handling & Rollback
Common Issues Handled:
- Tag created on wrong branch: Delete and recreate on correct branch
- Uncommitted changes discovered: Commit and restart tag process
- Test failures during QA phase: Fix and re-run tests before tagging
- Git conflicts during merge: Resolve and verify clean merge
- Version numbering inconsistencies: Validate across all files
- Documentation validation errors: Fix before proceeding
- CI/CD pipeline failures: Monitor and handle appropriately
Rollback Procedures:
- Automatic stash/unstash for failed operations
- Branch restoration from backup references
- Tag deletion for failed releases
- Commit reversion with explanatory messages
Configuration Options
Release Types:
- Standard Release: Full workflow with all checks
- Hotfix Release: Accelerated workflow for critical fixes
- Pre-release: Alpha/beta/rc versions with limited distribution
- Dry Run: Simulation mode without actual publishing
Safety Levels:
- Conservative: Strict checks, manual approvals at every step
- Balanced: Reasonable automation with key checkpoints
- Aggressive: Maximum automation, minimal human intervention
Success Criteria
A release is considered successful when:
- ✅ All tests pass consistently
- ✅ Pre-commit checks complete without errors
- ✅ Documentation is complete and accurate
- ✅ GIT TAG CREATED AT CORRECT MOMENT
- ✅ Version tags are properly pushed
- ✅ GitHub release is published successfully
- ✅ CI/CD pipelines complete successfully
- ✅ Package is available on PyPI
Emergency Procedures
For urgent releases:
- Fast-track critical fixes through abbreviated workflow
- Bypass non-essential checks with proper justification
- Coordinate with team for expedited review
- STILL FOLLOW PROPER TAG TIMING
- Document emergency release rationale
- Follow up with proper post-release validation
This skill ensures professional, reliable release management while maintaining flexibility for different scenarios and urgency levels.
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.

