What this prompt does
This prompt sets up fully automated GitHub releases for a [project_type] project driven by conventional commits. It maps commit types to semantic version bumps (feat to minor, fix to patch, BREAKING CHANGE to major), builds a GitHub Action workflow triggered on your [trigger_event], and auto-generates a changelog grouped into Features, Bug Fixes, Performance, and Breaking Changes. It also bumps version numbers in the files you specify so everything stays in sync.
It works because conventional commits already encode release intent, so the pipeline just reads them. The AI wires version bumping into your [version_files], uploads [build_artifacts] to the release, handles pre-releases from your [pre_release_branch], tags and pushes a Docker image to your [registry], and posts announcements to your [notification_channels]. The result is that every tag carries a clean changelog and the right artifacts without anyone hand-writing release notes, plus a documented rollback path for when a release ships a critical bug.
When to use it
- Shipping a library or app where every release needs a clean, consistent changelog
- Your team already uses (or wants to adopt) Conventional Commits
- You want version bumps and tags created automatically on
[trigger_event] - Releases must upload
[build_artifacts]like bundles, type declarations, or source maps - You publish Docker images and want them tagged with the release version in
[registry] - You want release announcements posted to
[notification_channels]automatically
Example output
You get a complete workflow: a GitHub Action YAML triggered on [trigger_event], semantic-version logic reading conventional commit types, a grouped auto-generated changelog, GitHub Release creation with the tag and changelog body, build-and-upload steps for [build_artifacts], a pre-release flow for [pre_release_branch] branches, notifications to [notification_channels], version bumping in [version_files], Docker tagging and push to [registry], and a documented rollback procedure for critical bugs.
Pro tips
- Make sure your team actually writes Conventional Commits; the whole version-bump logic depends on feat/fix/BREAKING CHANGE prefixes being used consistently
- Set
[trigger_event]to match your release model — push to main for continuous releases, or a tag/manual dispatch for gated ones - List
[build_artifacts]precisely so the workflow builds and attaches exactly what consumers need (bundle, types, source maps) - Point
[registry]and Docker tagging at your real container registry so images line up with the release version for deployments - Keep
[version_files]in sync (package.json, CHANGELOG.md) so the bumped version is consistent wherever it appears - Route release announcements to
[notification_channels]your team actually watches, so a new version doesn't ship unnoticed - Keep the rollback procedure handy; even automated releases ship bad versions occasionally, and knowing how to yank or revert one matters
- Use the
[pre_release_branch]flow to publish release candidates before promoting to a stable tag
