conventional-releaselisted

# Conventional Release A widely-used release pattern: every PR is **squash-merged**, its **title is a [Conventional Commit](https://www.conventionalcommits.org/)**, and an automated tool on the default branch reads the commit type to calculate the next [SemVer](https://semver.org/) tag, cut a release, and generate the changelog. No human writes a version number or a changelog entry by hand — the merge title *is* the release note, and the type *is* the bump. Use this skill whenever you open or merge a PR into a repository that releases this way, or when you need to decide which version a change should produce. ## How to tell a repo uses this pattern Look for any one of: - A release tool wired to run on push to the default branch: [`semantic-release`](https://github.com/semantic-release/semantic-release), [`release-please`](https://github.com/googleapis/release-please), [`mathieudutour/github-tag-action`](https://github.com/mathieudutour/github-tag-action), or [Changesets](https://github.com/changesets/changesets). - Branch protection that **only allows squash merging** (so the PR title is the sole commit message that reaches the default branch). - A `CHANGELOG.md` that is generated, or release notes grouped by `Features` / `Bug Fixes`. - A `commitlint`/`commitizen` config, or CI that lints the PR title against the Conventional Commits spec. If the repo squash-merges but releases manually, the title still matters for history and review — keep writing Conventio