clawhub install release-managerπ About This Skill
name: "release-manager" description: "Release Manager"
Release Manager
Tier: POWERFUL Category: Engineering Domain: Software Release Management & DevOps
Overview
The Release Manager skill provides comprehensive tools and knowledge for managing software releases end-to-end. From parsing conventional commits to generating changelogs, determining version bumps, and orchestrating release processes, this skill ensures reliable, predictable, and well-documented software releases.
Core Capabilities
Key Components
Scripts
1. changelog_generator.py - Parses git logs and generates structured changelogs 2. version_bumper.py - Determines correct version bumps from conventional commits 3. release_planner.py - Assesses release readiness and generates coordination plans
Documentation
Release Management Methodology
Semantic Versioning (SemVer)
Semantic Versioning follows the MAJOR.MINOR.PATCH format where:
#### Pre-release Versions
Pre-release versions are denoted by appending a hyphen and identifiers:
1.0.0-alpha.1 - Alpha releases for early testing1.0.0-beta.2 - Beta releases for wider testing1.0.0-rc.1 - Release candidates for final validation#### Version Precedence
Version precedence is determined by comparing each identifier:
1. 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta
2. 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1
3. 1.0.0-rc.1 < 1.0.0
Conventional Commits
Conventional Commits provide a structured format for commit messages that enables automated tooling:
#### Format
[optional scope]: [optional body]
[optional footer(s)]
#### Types
#### Examples
feat(user-auth): add OAuth2 integrationfix(api): resolve race condition in user creation
docs(readme): update installation instructions
feat!: remove deprecated payment API
BREAKING CHANGE: The legacy payment API has been removed
Automated Changelog Generation
Changelogs are automatically generated from conventional commits, organized by:
#### Structure
# Changelog[Unreleased]
Added
Changed
Deprecated
Removed
Fixed
Security
[1.2.0] - 2024-01-15
Added
OAuth2 authentication support (#123)
User preference dashboard (#145) Fixed
Race condition in user creation (#134)
Memory leak in image processing (#156) Breaking Changes
Removed legacy payment API
#### Grouping Rules
#### Metadata Extraction
(#123)auth:, api:, ui:Version Bump Strategies
Version bumps are determined by analyzing commits since the last release:
#### Automatic Detection Rules
1. MAJOR: Any commit with BREAKING CHANGE or ! after type
2. MINOR: Any feat type commits without breaking changes
3. PATCH: fix, perf, security type commits
4. NO BUMP: docs, style, test, chore, ci, build only
#### Pre-release Handling
# Alpha: 1.0.0-alpha.1 β 1.0.0-alpha.2
Beta: 1.0.0-alpha.5 β 1.0.0-beta.1
RC: 1.0.0-beta.3 β 1.0.0-rc.1
Release: 1.0.0-rc.2 β 1.0.0
#### Multi-package Considerations For monorepos with multiple packages:
@scope/package@1.2.3Release Branch Workflows
#### Git Flow
main (production) β release/1.2.0 β develop β feature/login
β hotfix/critical-fix
Advantages:
Process:
1. Create release branch from develop: git checkout -b release/1.2.0 develop
2. Finalize release (version bump, changelog)
3. Merge to main and develop
4. Tag release: git tag v1.2.0
5. Deploy from main
#### Trunk-based Development
main β feature/login (short-lived)
β feature/payment (short-lived)
β hotfix/critical-fix
Advantages:
Process: 1. Short-lived feature branches (1-3 days) 2. Frequent commits to main 3. Feature flags for incomplete features 4. Automated testing gates 5. Deploy from main with feature toggles
#### GitHub Flow
main β feature/login
β hotfix/critical-fix
Advantages:
Process: 1. Create feature branch from main 2. Regular commits and pushes 3. Open pull request when ready 4. Deploy from feature branch for testing 5. Merge to main and deploy
Feature Flag Integration
Feature flags enable safe, progressive rollouts:
#### Types of Feature Flags
#### Implementation Strategy
# Progressive rollout example
if feature_flag("new_payment_flow", user_id):
return new_payment_processor.process(payment)
else:
return legacy_payment_processor.process(payment)
#### Release Coordination 1. Deploy code with feature behind flag (disabled) 2. Gradually enable for percentage of users 3. Monitor metrics and error rates 4. Full rollout or quick rollback based on data 5. Remove flag in subsequent release
Release Readiness Checklists
#### Pre-Release Validation
#### Quality Gates
#### Documentation Requirements
#### Stakeholder Approvals
Deployment Coordination
#### Communication Plan Internal Stakeholders:
External Communication:
#### Deployment Sequence 1. Pre-deployment (T-24h): Final validation, freeze code 2. Database migrations (T-2h): Run and validate schema changes 3. Blue-green deployment (T-0): Switch traffic gradually 4. Post-deployment (T+1h): Monitor metrics and logs 5. Rollback window (T+4h): Decision point for rollback
#### Monitoring & Validation
Hotfix Procedures
Hotfixes address critical production issues requiring immediate deployment:
#### Severity Classification P0 - Critical: Complete system outage, data loss, security breach
P1 - High: Major feature broken, significant user impact
P2 - Medium: Minor feature issues, limited user impact
#### Emergency Response Process 1. Incident declaration: Page on-call team 2. Assessment: Determine severity and impact 3. Hotfix branch: Create from last stable release 4. Minimal fix: Address root cause only 5. Expedited testing: Automated tests + manual validation 6. Emergency deployment: Deploy to production 7. Post-incident: Root cause analysis and prevention
Rollback Planning
Every release must have a tested rollback plan:
#### Rollback Triggers
#### Rollback Types Code Rollback:
Database Rollback:
Infrastructure Rollback:
#### Automated Rollback
# Example rollback automation
def monitor_deployment():
if error_rate() > THRESHOLD:
alert_oncall("Error rate spike detected")
if auto_rollback_enabled():
execute_rollback()
Release Metrics & Analytics
#### Key Performance Indicators
#### Quality Metrics
#### Process Metrics
Tool Integration
#### Version Control Systems
#### CI/CD Platforms
#### Monitoring & Alerting
#### Communication Platforms
Best Practices
Release Planning
1. Regular cadence: Establish predictable release schedule 2. Feature freeze: Lock changes 48h before release 3. Risk assessment: Evaluate changes for potential impact 4. Stakeholder alignment: Ensure all teams are preparedQuality Assurance
1. Automated testing: Comprehensive test coverage 2. Staging environment: Production-like testing environment 3. Canary releases: Gradual rollout to subset of users 4. Monitoring: Proactive issue detectionCommunication
1. Clear timelines: Communicate schedules early 2. Regular updates: Status reports during release process 3. Issue transparency: Honest communication about problems 4. Post-mortems: Learn from incidents and improveAutomation
1. Reduce manual steps: Automate repetitive tasks 2. Consistent process: Same steps every time 3. Audit trails: Log all release activities 4. Self-service: Enable teams to deploy safelyCommon Anti-patterns
Process Anti-patterns
Technical Anti-patterns
Cultural Anti-patterns
Getting Started
1. Assessment: Evaluate current release process and pain points 2. Tool setup: Configure scripts for your repository 3. Process definition: Choose appropriate workflow for your team 4. Automation: Implement CI/CD pipelines and quality gates 5. Training: Educate team on new processes and tools 6. Monitoring: Set up metrics and alerting for releases 7. Iteration: Continuously improve based on feedback and metrics
The Release Manager skill transforms chaotic deployments into predictable, reliable releases that build confidence across your entire organization.
π‘ Examples
feat(user-auth): add OAuth2 integrationfix(api): resolve race condition in user creation
docs(readme): update installation instructions
feat!: remove deprecated payment API
BREAKING CHANGE: The legacy payment API has been removed
Automated Changelog Generation
Changelogs are automatically generated from conventional commits, organized by:
#### Structure ```markdown