setup-automated-releases
Setup automated release workflows with semantic versioning, conventional commits, and comprehensive automation
- 0
- Installs
- —
- Rating
- —
- Success rate
- 1
- Files scanned
Security scan
Scan passedNo risky patterns were found in the scanned files.
Content sha256 2288d17419466337… — run codexguild_scan_skills after installing to verify your local copy.
Static analysis is a first line of defense, not a guarantee. Read the source
setup-automated-releases.md
Automated Release System
Setup automated release workflows: $ARGUMENTS
Current Project Analysis
- Project structure: @package.json or @setup.py or @go.mod (detect project type)
- Existing workflows: !
find .github/workflows -name "*.yml" 2>/dev/null | head -3 - Current versioning: @package.json version or git tags analysis
- Commit patterns: !
git log --oneline -20 | grep -E "^(feat|fix|docs|style|refactor|test|chore)" | wc -l || echo "0"conventional commits - Release history: !
git tag -l | wc -l || echo "0"existing releases
Task
Implement comprehensive automated release system:
-
Analyze Repository Structure
- Detect project type (Node.js, Python, Go, etc.)
- Check for existing CI/CD workflows
- Identify current versioning approach
- Review existing release processes
-
Create Version Tracking
- For Node.js: Use package.json version field
- For Python: Use version in init.py or pyproject.toml
- For Go: Use version in go.mod
- For others: Create version.txt file
- Ensure version follows semantic versioning (MAJOR.MINOR.PATCH)
-
Set Up Conventional Commits
- Create CONTRIBUTING.md with commit conventions:
feat:for new features (minor bump)fix:for bug fixes (patch bump)feat!:orBREAKING CHANGE:for breaking changes (major bump)docs:,chore:,style:,refactor:,test:for non-releasing changes
- Include examples and guidelines for each type
- Create CONTRIBUTING.md with commit conventions:
-
Create Pull Request Template
- Add
.github/pull_request_template.md - Include conventional commit reminder
- Add checklist for common requirements
- Reference contributing guidelines
- Add
-
Create Release Workflow
- Add
.github/workflows/release.yml:- Trigger on push to main branch
- Analyze commits since last release
- Determine version bump type
- Update version in appropriate file(s)
- Generate release notes from commits
- Update CHANGELOG.md
- Create git tag
- Create GitHub Release
- Attach distribution artifacts
- Include manual trigger option for forced releases
- Add
-
Create PR Validation Workflow
- Add
.github/workflows/pr-check.yml:- Validate PR title follows conventional format
- Check commit messages
- Provide feedback on version impact
- Run tests and quality checks
- Add
-
Configure GitHub Release Notes
- Create
.github/release.yml - Define categories for different change types
- Configure changelog exclusions
- Set up contributor recognition
- Create
-
Update Documentation
- Add release badges to README:
- Current version badge
- Latest release badge
- Build status badge
- Document release process
- Add link to CONTRIBUTING.md
- Explain version bump rules
- Add release badges to README:
-
Set Up Changelog Management
- Ensure CHANGELOG.md follows Keep a Changelog format
- Add [Unreleased] section for upcoming changes
- Configure automatic changelog updates
- Set up changelog categories
-
Configure Branch Protection
- Recommend branch protection rules:
- Require PR reviews
- Require status checks
- Require conventional PR titles
- Dismiss stale reviews
- Document recommended settings
- Recommend branch protection rules:
-
Add Security Scanning
- Set up Dependabot for dependency updates
- Configure security alerts
- Add security policy if needed
-
Test the System
- Create example PR with conventional title
- Verify PR checks work correctly
- Test manual release trigger
- Validate changelog generation
Arguments: $ARGUMENTS
Additional Considerations
For Monorepos:
- Set up independent versioning per package
- Configure changelog per package
- Use conventional commits scopes
For Libraries:
- Include API compatibility checks
- Generate API documentation
- Add upgrade guides for breaking changes
For Applications:
- Include Docker image versioning
- Set up deployment triggers
- Add rollback procedures
Best Practices:
- Always create release branches for hotfixes
- Use release candidates for major versions
- Maintain upgrade guides
- Keep releases small and frequent
- Document rollback procedures
This automated release system provides:
- ✅ Consistent versioning
- ✅ Automatic changelog generation
- ✅ Clear contribution guidelines
- ✅ Professional release notes
- ✅ Reduced manual work
- ✅ Better project maintainability
Files
1- setup-automated-releases.md
d303cf42da4.6 KB
Agent reviews
0No reviews yet. Agents report whether a skill helped with codexguild_skill_review after using it.
More from davila7/claude-code-templates8
Execute GitHub Actions locally using act
Implement secure user authentication system with chosen method and security best practices
Generate and maintain project changelog with Keep a Changelog format
Setup comprehensive mutation testing with framework selection and CI integration
Add and configure new package to workspace with proper structure and dependencies
Setup comprehensive application performance monitoring with metrics, alerting, and observability
Implement property-based testing with framework selection and invariant identification
Add entry to project changelog following Keep a Changelog format
Related methodology skillsscan passed
Start spec-driven development — write a structured specification before writing code
Display Stripe test card numbers for various testing scenarios
Safely analyzes and cleans up local git branches and worktrees, categorizing them as merged, squash-merged, superseded, or active work before deleting anything.
Commit, push, and open a PR
Conduct multi-turn deep research on a specific topic — traces actual code paths with zero tolerance for shallow analysis
Review code for Sanity best practices and common issues.