Install any skill in seconds. Free to start, no credit card required.
Get Started Free →cherryhq/prepare-release
Prepare a new release by collecting commits, generating bilingual release notes, updating version files, and creating a release branch with PR.
Passed 12 of 17 test cases with the skill, and 6 of 17 without it.
and 10 more in the full report
8 fixed8 passed either way7 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
When preparing a release locally for version 1.8.1, in what order should validate-prepared-release.js and build:builtin-knowledge be run?
| Checked | Without skill | With skill |
|---|---|---|
| Executes validate-prepared-release.js before executing build:builtin-knowledge. | Missed | Passed |
The instructions your model reads when the skill loads.
Automate the Cherry Studio release workflow: collect changes → generate bilingual release notes → update files → create release branch → trigger CI/CD.
Parse the version intent from the user's message. Accept any of these forms:
patch, minor, majorx.y.z or x.y.z-<prerelease> without build metadata (e.g. 1.8.0, 1.8.0-beta.1, 1.8.0-rc.1)Defaults to patch if no version is specified. Always echo the resolved target version back to the user before proceeding with any file edits.
--dry-run: Preview only, do not create a release branch.origin/main and all tags, then verify that the checkout is a clean main at exactly origin/main:
git fetch origin refs/heads/main:refs/remotes/origin/main --tags
test "$(git branch --show-current)" = main
test -z "$(git status --porcelain)"
test "$(git rev-parse HEAD)" = "$(git rev-parse origin/main)"
Stop before editing files if any check fails. This prevents a standalone run from creating a release branch from an arbitrary or stale checkout.
In GitHub Actions, use the workflow's frozen dispatch SHA and leave checkout validation to the workflow. Do not fetch or compare the later origin/main head.package.json. Post Release keeps this synchronized with the last published release.v{current-version} and verify that it exists:
git rev-parse --verify refs/tags/v{current-version}
Stop if it is missing. Confirm that it is also the latest published, non-draft GitHub Release whose tag is strict v<semver>; non-semver preview releases are never a release baseline:
gh release list --limit 1000 --json isDraft,publishedAt,tagName --jq '[.[] | select(.isDraft == false and (.tagName | test("^v(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\.[0-9A-Za-z-]+)*)?$")))] | sort_by(.publishedAt) | last | .tagName // empty'
Stop on a mismatch: the latest Post Release metadata PR must be merged into main before another release is prepared.patch / minor / major: bump from the current version.test cases passed, vs 6 / 17 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.