## TL;DR
semantic-release found no commits matching its release rules since the last release, so it correctly published nothing. Make the change as a Conventional Commit (`feat:`, `fix:`, or a breaking-change footer) or point CI at the right release branch, then rerun. No matching commits means no version bump and no changelog update by design.

## The error
```text
no new release
```

## Steps
1. Run a dry run and read the analysis: `npx semantic-release --dry-run`. Expected: the log lists the commits it examined and ends with "no new release".
2. Check recent commits for release-worthy prefixes: `git log --oneline -15`. Expected: you can see whether any commit starts with `feat:`, `fix:`, `perf:`, or carries a breaking-change marker.
3. Check that CI ran on a release branch: compare the branch name against the branches list in the release config (`.releaserc.json`, `.releaserc`, or the `release` key in `package.json`). Expected: the branch CI used is listed as a release branch.
4. If commits lack prefixes, create the change as a conventional commit (for example `feat: add search filters`) or squash-merge the PR with a conventional title. Expected: `git log` shows the new commit with a valid prefix.
5. Rerun the pipeline. Expected: semantic-release publishes a new version and appends the entry to the changelog.

## Use this when
- CI finishes green but semantic-release reports "no new release".
- The changelog was not updated after a merge you expected to release.
- You are setting up semantic-release for the first time and nothing publishes.

## Not for this skill when
- semantic-release crashes with an auth or plugin error - that is configuration, not commit analysis.
- You intentionally want no release; the tool is behaving correctly.
- Commits use a custom convention your config does not define - check the preset first.

## Variant phrasings
### semantic release did not publish anything
Same outcome described from the CI side. Same fix.
### no release published by semantic-release
Same. Check commits and branches.
### changelog not updated after merge
When the merge used a non-conventional message, the changelog stays untouched. Same fix.

## Why it happens
semantic-release decides the next version purely from commit messages since the last release. Merges with plain titles like "update stuff" or "wip" match no rule, so the analyzer concludes there is nothing to release. Running on a non-release branch has the same visible effect, because the tool only evaluates release branches.

## Edge cases
- Squash merges: the squashed message is what matters, not the individual PR commits. Require conventional PR titles if you squash.
- `chore:` and `docs:` commits never trigger releases by default. A release that should have shipped needs `feat:`, `fix:`, or `perf:`.
- A dry run on a detached HEAD or a shallow clone can misread history. Run it on the real branch with full history when diagnosing.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ij1A0W0ZzWmH26PsSODuDQ