agentleFS
tanbrotanbro/uiautomator2-mcp-server/skills/release-manager/SKILL.md

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

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.
  • arnaudgelasSkill

    qa-agent

    Answer questions from the vault, then file durable insights back into the knowledge base.

    Also in 3 projects that use this

  • mar-antayaSkill

    dependency-auditor

    Dependency Auditor

    Also in 3 projects that use this

  • ArogyaReddySkill

    changelog-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

  • MicrosoftSkill

    playwright-cli

    Automate browser interactions, test web pages and work with Playwright tests.

    Also in 3 projects that use this

  • SentrySkill

    skill-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

  • GoogleSkill

    grill-me

    A relentless interview to sharpen a plan or design.

    Also in 3 projects that use this

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
  1. Distinctive:

    Ensure code quality and documentation completeness before release

    line 48
  2. Distinctive:

    Check version numbers and changelog entries

    line 66
  3. Distinctive:

    CRITICAL: Verify all untracked files are handled (committed or .gitignore'd)

    line 67
  4. Distinctive:

    Verify working directory is clean (no uncommitted changes)

    line 68
  5. Distinctive:

    Run comprehensive test suite

    line 74
  6. Distinctive:

    Check for breaking changes and migration guides

    line 77
  7. Distinctive:

    Update version numbers if needed

    line 82
  8. Distinctive:

    Update README and other documentation

    line 84
  9. Distinctive:

    VERIFY: all changes are committed (check git status - clean working directory)

    line 94
  10. Distinctive:

    Verify PyPI package publication

    line 110
  11. Distinctive:

    Tag created on wrong branch: Delete and recreate on correct branch

    line 153
  12. Distinctive:

    Uncommitted changes discovered: Commit and restart tag process

    line 154
  13. Distinctive:

    Commit reversion with explanatory messages

    line 165
  14. Distinctive:

    Document emergency release rationale

    line 199
  15. Distinctive:

    Follow up with proper post-release validation

    line 200

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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: develop branch
  • Release commits created on: develop branch
  • Merge direction: develop → main (or master)
  • Tag location: main (or master) 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

  1. Assess current Git status and branch position
  2. Review recent commits and changes since last release
  3. Check version numbers and changelog entries
  4. CRITICAL: Verify all untracked files are handled (committed or .gitignore'd)
  5. Verify working directory is clean (no uncommitted changes)
  6. Evaluate overall project health and readiness

⚠️ NO git operations in this phase

Phase 2: Quality Assurance

  1. Run comprehensive test suite
  2. Execute pre-commit checks and linting
  3. Validate documentation completeness
  4. Check for breaking changes and migration guides

⚠️ NO git operations in this phase

Phase 3: Preparation

  1. Update version numbers if needed
  2. Finalize CHANGELOG entries
  3. Update README and other documentation
  4. 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)

  1. VERIFY all changes are committed (check git status - clean working directory)
  2. CREATE FINAL RELEASE COMMIT on develop branch
  3. SWITCH to main/master branch: git checkout main (or master)
  4. MERGE develop to main/master: git merge develop
  5. VERIFY merge is clean (fast-forward preferred, or clean merge)
  6. VERIFY on correct branch (main/master)
  7. VERIFY working directory is still clean
  8. CREATE GIT TAG on main/master ← THE FINAL STEP
    • This is the LAST action before pushing
    • NOTHING should happen after tagging except push
  9. PUSH main/master branch to remote
  10. PUSH tag to remote
  11. Monitor CI/CD pipeline status

Phase 5: Verification

  1. Confirm successful GitHub release creation
  2. Verify PyPI package publication
  3. Check documentation deployment
  4. 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:

  1. Fast-track critical fixes through abbreviated workflow
  2. Bypass non-essential checks with proper justification
  3. Coordinate with team for expedited review
  4. STILL FOLLOW PROPER TAG TIMING
  5. Document emergency release rationale
  6. Follow up with proper post-release validation

This skill ensures professional, reliable release management while maintaining flexibility for different scenarios and urgency levels.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.