name	release
description	Prepare a SearchMark release — bump the version in package.json, draft the CHANGELOG.md section from commits since the last tag, and hand back for the user to commit. Use when asked to release, cut a release, bump the version, or update the changelog for a release.

Release SearchMark

Pushing a version bump to main triggers .github/workflows/release.yml: CI, store submission (Chrome + Firefox), and a GitHub release whose notes are the matching ## [x.y.z] section of CHANGELOG.md. This skill only prepares the release commit — the user reviews, commits, and pushes.

Steps

Collect changes since the last release:
```
LAST=$(git tag --sort=-v:refname | head -1)
git log --oneline "$LAST"..HEAD
```
If there are no releasable commits (only chores/deps/CI), say so and stop.
Infer the bump from conventional commit prefixes, then confirm with the user (AskUserQuestion) before writing anything:
- breaking change → major
- any feat: → minor
- otherwise (fix: etc.) → patch
Draft the changelog section and prepend it to CHANGELOG.md right after the intro (above the previous ## [x.y.z]):
```
## [x.y.z]

### Added
- ...

### Changed
- ...

### Fixed
- ...
```
Rules (match the existing file):
- User-facing wording, not commit messages — describe what the user notices, read the diff if a commit subject is unclear.
- Only include ### Added / ### Changed / ### Fixed / ### Removed headings that have entries.
- Skip chores, deps bumps, CI, tests, docs, refactors with no visible effect.
- No dates, no links — the file doesn't use them.
Bump the version in package.json ("version" field only — nothing else references the version; the manifest gets it from there at build time).
Hand back. Show the drafted section and suggest the commit message (matches history):
```
chore(release): bump version to x.y.z
```
The commit should touch only package.json and CHANGELOG.md. Do not commit or push. Remind that pushing to main submits to both stores.

Gotchas

The workflow only fires when v<package.json version> has no existing tag — a push without a bump does nothing; a wrong version already tagged silently skips release.
Release notes are extracted by changelog-reader-action matching ## [x.y.z] exactly — keep the bracketed heading format.

Release SearchMark

Steps

Collect changes since the last release:

LAST=$(git tag --sort=-v:refname | head -1)
git log --oneline "$LAST"..HEAD

If there are no releasable commits (only chores/deps/CI), say so and stop.

Infer the bump from conventional commit prefixes, then confirm with the user (AskUserQuestion) before writing anything:

breaking change → major
any feat: → minor
otherwise (fix: etc.) → patch

Draft the changelog section and prepend it to CHANGELOG.md right after the intro (above the previous ## [x.y.z]):

## [x.y.z]

### Added
- ...

### Changed
- ...

### Fixed
- ...

Rules (match the existing file):

User-facing wording, not commit messages — describe what the user notices, read the diff if a commit subject is unclear.
Only include ### Added / ### Changed / ### Fixed / ### Removed headings that have entries.
Skip chores, deps bumps, CI, tests, docs, refactors with no visible effect.
No dates, no links — the file doesn't use them.

Bump the version in package.json ("version" field only — nothing else references the version; the manifest gets it from there at build time).

Hand back. Show the drafted section and suggest the commit message (matches history):

chore(release): bump version to x.y.z

The commit should touch only package.json and CHANGELOG.md. Do not commit or push. Remind that pushing to main submits to both stores.

Gotchas

The workflow only fires when v<package.json version> has no existing tag — a push without a bump does nothing; a wrong version already tagged silently skips release.

Release notes are extracted by changelog-reader-action matching ## [x.y.z] exactly — keep the bracketed heading format.