Comprehensive GitHub release orchestration with AI swarm coordination for automated versioning, testing, deployment, and rollback management. Coordinates release-manager, cicd-engineer, tester, and docs-writer agents through hierarchical topology to handle semantic versioning, changelog generation, release notes, deployment validation, and post-release monitoring. Supports multiple release strategies (rolling, blue-green, canary) and automated rollback. Use when creating releases, managing deployments, or coordinating version updates. Use when this capability is needed.
Comprehensive GitHub release orchestration with AI swarm coordination for automated versioning, testing, deployment, and rollback management. Coordinates release-manager, cicd-engineer, tester, and docs-writer agents through hierarchical topology to handle semantic versioning, changelog generation, release notes, deployment validation, and post-release monitoring. Supports multiple release strategies (rolling, blue-green, canary) and automated rollback. Use when creating releases, managing deployments, or coordinating version updates. Use when this capability is needed.
metadata
{"author":"dnyoussef"}
GitHub Release Management Skill
Overview
Orchestrate end-to-end software release processes with intelligent agent coordination. This skill automates version bumping, changelog generation, release candidate testing, deployment orchestration, post-release validation, and rollback procedures for GitHub-hosted projects using comprehensive CI/CD integration.
When to Use This Skill
Activate this skill when creating production releases with automated validation, coordinating multi-environment deployments (staging, production), generating release notes and changelogs automatically, managing semantic versioning across projects, implementing deployment strategies (rolling, blue-green, canary), handling hotfix releases and emergency patches, or establishing release automation for new projects.
Use for both small single-repository releases and complex multi-service deployments, scheduled regular releases or on-demand deployments, and establishing release governance and compliance.
Agent Coordination Architecture
Swarm Topology
Initialize a hierarchical topology with release-manager as coordinator overseeing specialized deployment, testing, and documentation agents. Hierarchical structure ensures coordinated decision-making for critical release operations.
Execute full release cycle from version bump to production deployment.
Phase 1: Pre-Release Preparation
Step 1.1: Initialize Release Swarm
# Set up hierarchical release swarm
mcp__claude-flow__swarm_init topology=hierarchical maxAgents=8 strategy=specialized
# Spawn release team
mcp__claude-flow__agent_spawn type=coordinator name=release-manager
mcp__claude-flow__agent_spawn type=coder name=cicd-engineer
mcp__claude-flow__agent_spawn type=researcher name=tester
mcp__claude-flow__agent_spawn type=analyst name=reviewer
mcp__claude-flow__agent_spawn type=researcher name=docs-writer
Step 1.2: Determine Release Version
Task("Release Manager", "
Determine next release version:
1. Fetch current version from package.json / Cargo.toml / VERSION file
2. Analyze commits since last release using git log
3. Classify changes: breaking|features|fixes|docs
4. Apply semantic versioning rules:
- Breaking changes → major version bump
- New features → minor version bump
- Bug fixes only → patch version bump
5. Check for forced version override in environment
Use scripts/semver.sh for version calculation
Store version decision in memory: release/version
Run hooks: npx claude-flow@alpha hooks pre-task --description 'version determination'
", "release-manager")
# Calculate next version
NEXT_VERSION=$(bash scripts/semver.sh calculate \
--current $(cat VERSION) \
--commits-since-tag "v$(cat VERSION)" \
--bump-strategy "auto")
Task("CI/CD Engineer", "
Update version across project files:
1. Update package.json version field
2. Update Cargo.toml version (if Rust project)
3. Update VERSION or version.txt file
4. Update hardcoded versions in documentation
5. Update version constants in source code
6. Commit changes: 'chore: bump version to ${NEXT_VERSION}'
Use scripts/version-bumper.sh for automation
Store version update status in memory: release/version-update
", "cicd-engineer")
Phase 2: Release Candidate Testing
Step 2.1: Build Release Candidate
Task("CI/CD Engineer", "
Build release candidate artifacts:
1. Trigger CI build for release branch
2. Run full test suite (unit, integration, e2e)
3. Build production artifacts (binaries, containers, packages)
4. Sign artifacts with release signing key
5. Upload artifacts to staging repository
6. Generate artifact checksums
Use scripts/build-release.sh
Store build artifacts in memory: release/artifacts
", "cicd-engineer")
Task("Test Engineer", "
Validate release candidate in staging:
1. Run smoke tests against staging deployment
2. Execute regression test suite
3. Perform load testing with production-like traffic
4. Validate API compatibility and contracts
5. Check database migrations successful
6. Test rollback procedure
7. Verify monitoring and alerting working
Use scripts/release-validation.sh
Store test results in memory: release/validation
", "tester")
Step 2.4: Security and Compliance Review
Task("Code Reviewer", "
Perform final security and compliance checks:
1. Scan for known vulnerabilities (npm audit, cargo audit)
2. Check for exposed secrets in release branch
3. Validate license compliance
4. Review CHANGELOG for security advisories
5. Check compliance with organizational policies
6. Approve or flag issues blocking release
Use references/security-checklist.md
Store review status in memory: release/security-review
", "reviewer")
Phase 3: Release Artifact Generation
Step 3.1: Generate Changelog
Task("Documentation Writer", "
Generate comprehensive changelog:
1. Fetch all commits since last release
2. Categorize by type: breaking|features|fixes|docs|chore
3. Extract issue references and PR numbers
4. Format using references/changelog-template.md
5. Highlight breaking changes prominently
6. Include migration guide if breaking changes present
Use scripts/changelog-generator.sh
Store changelog in memory: release/changelog
", "docs-writer")
Step 3.2: Write Release Notes
Task("Documentation Writer", "
Create user-facing release notes:
1. Summarize major features and improvements
2. Document breaking changes with upgrade path
3. List bug fixes with issue references
4. Include known issues and workarounds
5. Add installation/upgrade instructions
6. Acknowledge contributors
Use references/release-notes-template.md
Store release notes in memory: release/notes
", "docs-writer")
Step 3.3: Update Documentation
# Update version in documentation
bash scripts/docs-updater.sh \
--version "${NEXT_VERSION}" \
--changelog "CHANGELOG.md" \
--docs-dir "docs/"
Task("Release Manager", "
Make final go/no-go decision:
1. Review all agent findings from memory
2. Check validation test results: release/validation
3. Verify security review passed: release/security-review
4. Confirm stakeholder approval received
5. Validate deployment window available
6. Make final decision: proceed or abort
Store decision in memory: release/go-no-go
", "release-manager")
Step 4.3: Execute Production Deployment
Task("CI/CD Engineer", "
Deploy release to production:
1. Select deployment strategy from references/deployment-strategies.md
- Rolling: gradual instance replacement
- Blue-Green: parallel environment swap
- Canary: phased rollout with traffic splitting
2. Execute deployment with chosen strategy
3. Monitor deployment health metrics
4. Validate deployment success criteria
5. Keep rollback option available
Use scripts/deploy.sh with strategy flag
Store deployment status in memory: release/deployment
", "cicd-engineer")
Task("Test Engineer", "
Validate production deployment:
1. Run production smoke test suite
2. Validate critical user journeys
3. Check error rates and latency metrics
4. Verify monitoring dashboards showing healthy state
5. Test rollback procedure (in separate environment)
Use scripts/production-validation.sh
Store validation results in memory: release/prod-validation
", "tester")
Step 5.2: Publish GitHub Release
Once production validated, publish the draft release:
Task("Release Manager", "
Monitor post-release health:
1. Track error rates for 24 hours post-release
2. Monitor user reports and support tickets
3. Watch for performance degradation
4. Check for unexpected edge cases
5. Prepare hotfix if critical issues discovered
Use scripts/release-monitoring.sh
Store monitoring data in memory: release/monitoring
", "release-manager")
Step 5.4: Merge Release Branch
# Merge release branch back to main
git checkout main
git merge --no-ff "release/v${NEXT_VERSION}"
git tag "v${NEXT_VERSION}"
git push origin main --tags
# Merge to develop if using gitflow
git checkout develop
git merge --no-ff "release/v${NEXT_VERSION}"
git push origin develop
Workflow 2: Hotfix Release
Execute emergency patch release for critical production issues.
Phase 1: Hotfix Initiation
Step 1.1: Create Hotfix Branch
# Create hotfix branch from production tag
git checkout -b "hotfix/v${CURRENT_VERSION}-hotfix.1""v${CURRENT_VERSION}"
git push origin "hotfix/v${CURRENT_VERSION}-hotfix.1"
Step 1.2: Apply Fix and Test
Task("CI/CD Engineer", "
Apply hotfix and validate:
1. Cherry-pick fix commits to hotfix branch
2. Bump version with hotfix suffix
3. Run targeted regression tests
4. Build hotfix artifacts
5. Deploy to staging for validation
6. Document fix in hotfix-specific changelog
Use scripts/hotfix.sh for automation
Store hotfix status in memory: release/hotfix
", "cicd-engineer")
Phase 2: Expedited Deployment
Step 2.1: Fast-Track Approval
Task("Release Manager", "
Expedite hotfix approval:
1. Assess severity and urgency
2. Fast-track security review (critical paths only)
3. Skip non-critical validation steps
4. Get stakeholder approval via emergency process
5. Approve for immediate production deployment
Store approval in memory: release/hotfix-approval
", "release-manager")
Step 2.2: Deploy Hotfix
# Deploy hotfix to production immediately
bash scripts/deploy.sh \
--environment "production" \
--version "${HOTFIX_VERSION}" \
--strategy "rolling" \
--fast-rollout true
Step 2.3: Backport Hotfix
# Merge hotfix to main and develop branches
git checkout main
git merge --no-ff "hotfix/${HOTFIX_VERSION}"
git push origin main
git checkout develop
git merge --no-ff "hotfix/${HOTFIX_VERSION}"
git push origin develop
Workflow 3: Rollback Management
Handle failed deployments with automated rollback.
Task("Release Manager", "
Assess deployment health and determine if rollback needed:
1. Check error rate spike (>5% increase)
2. Monitor latency degradation (>50% increase)
3. Track failed health checks
4. Review user impact reports
5. Make rollback decision based on severity
Use references/rollback-criteria.md
Store decision in memory: release/rollback-decision
", "release-manager")
Phase 2: Rollback Execution
Step 2.1: Trigger Automated Rollback
# Execute rollback to previous version
bash scripts/rollback.sh \
--environment "production" \
--target-version "${PREVIOUS_VERSION}" \
--strategy "immediate" \
--preserve-data true
Step 2.2: Validate Rollback Success
Task("Test Engineer", "
Validate rollback restored service:
1. Confirm previous version deployed
2. Run smoke tests
3. Verify error rates normalized
4. Check data integrity maintained
5. Monitor for 1 hour post-rollback
Store rollback validation in memory: release/rollback-validation
", "tester")
Step 2.3: Post-Mortem Analysis
Task("Release Manager", "
Conduct rollback post-mortem:
1. Document failure root cause
2. Identify what testing missed the issue
3. Create action items to prevent recurrence
4. Update release process with learnings
5. Schedule fix and re-release
Use references/postmortem-template.md
Store post-mortem in memory: release/postmortem
", "release-manager")
Deployment Strategies
Rolling Deployment
Gradually replace instances with new version. Default strategy for most releases.
Characteristics:
Low risk: issues affect subset of users
Gradual rollout: 10% → 25% → 50% → 100%
Easy rollback: stop deployment and roll back affected instances
No extra infrastructure required
Blue-Green Deployment
Maintain two identical environments, switch traffic atomically.
Characteristics:
Zero downtime: instant traffic switch
Easy rollback: switch traffic back
Requires 2x infrastructure temporarily
Good for database migration testing
Canary Deployment
Route small percentage of traffic to new version, gradually increase.
