Prepare Release

Automate the Cherry Studio release workflow: collect changes → generate bilingual release notes → update files → create release branch + PR → trigger CI/CD.

Arguments

Parse the version intent from the user's message. Accept any of these forms:

• Bump type keyword: patch , minor , major

• Exact version: x.y.z or x.y.z-pre.N (e.g. 1.8.0 , 1.8.0-beta.1 , 1.8.0-rc.1 )

• Natural language: "prepare a beta release", "bump to 1.8.0-rc.2", etc.

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 branch or PR.

Workflow

Step 1: Determine Version

• Get the latest tag: git describe --tags --abbrev=0

• Read current version from package.json .

• Compute the new version based on the argument:

• patch / minor / major : bump from the current tag version.

• x.y.z or x.y.z-pre.N : use as-is after validating it is valid semver.

Step 2: Collect Commits

• List all commits since the last tag: git log <last-tag>..HEAD --format="%H %s" --no-merges

• For each commit, get the full body: git log <hash> -1 --format="%B"

• Extract the content inside ```release-note code blocks from each commit body.

• Extract the conventional commit type from the title (feat , fix , refactor , perf , docs , etc.).

• Skip these commits:

• Titles starting with 🤖 Daily Auto I18N

• Titles starting with Merge

• Titles starting with chore(deps)

• Titles starting with chore: release

• Commits where the release-note block says NONE

Step 3: Generate Bilingual Release Notes

Using the collected commit information, generate release notes in both English and Chinese.

Format (must match exactly):

<!--LANG:en--> Cherry Studio {version} - {Brief English Title}

✨ New Features

• [Component] Description

🐛 Bug Fixes

• [Component] Description

💄 Improvements

• [Component] Description

⚡ Performance

• [Component] Description

<!--LANG:zh-CN--> Cherry Studio {version} - {简短中文标题}

✨ 新功能

• [组件] 描述

🐛 问题修复

• [组件] 描述

💄 改进

• [组件] 描述

⚡ 性能优化

• [组件] 描述 <!--LANG:END-->

Rules:

• Only include categories that have entries (omit empty categories).

• Each commit appears as exactly ONE line item in the appropriate category.

• Use the release-note field if present; otherwise summarize from the commit title.

• Component tags should be short: [Chat] , [Models] , [Agent] , [MCP] , [Settings] , [Data] , [Build] , etc.

• Chinese translations should be natural, not machine-literal.

• Do NOT include commit hashes or PR numbers.

• Read the existing release notes in electron-builder.yml as a style reference before writing.

IMPORTANT: User-Focused Content Only

Release notes are for end users, not developers. Exclude anything users don't care about:

• EXCLUDE internal refactoring, code cleanup, or architecture changes

• EXCLUDE CI/CD, build tooling, or test infrastructure changes

• EXCLUDE dependency updates (unless they add user-visible features)

• EXCLUDE documentation updates

• EXCLUDE developer experience improvements

• EXCLUDE technical debt fixes with no user-visible impact

• EXCLUDE overly technical descriptions (e.g., "fix race condition in Redux middleware")

INCLUDE only changes that users will notice:

• New features they can use

• Bug fixes that affected their workflow

• UI/UX improvements they can see

• Performance improvements they can feel

• Security fixes (simplified, without implementation details)

Keep descriptions simple and non-technical:

• ❌ "Fix streaming race condition causing partial tool response status in Redux state"

• ✅ "Fix tool status not stopping when aborting"

• ❌ "Auto-convert reasoning_effort to reasoningEffort for OpenAI-compatible providers"

• ✅ "Fix deep thinking mode not working with some providers"

Step 4: Update Files

• package.json : Update the "version" field to the new version.

• electron-builder.yml : Replace the content under releaseInfo.releaseNotes: | with the generated notes. Preserve the 4-space YAML indentation for the block scalar content.

Step 5: Present for Review

Show the user:

• The new version number.

• The full generated release notes.

• A summary of which files were modified.

If --dry-run was specified, stop here.

Otherwise, ask the user to confirm before proceeding to Step 6.

Step 6: Create Branch and PR

• Create and push the release branch: git checkout -b release/v{version} git add package.json electron-builder.yml git commit -m "chore: release v{version}" git push -u origin release/v{version}

• Create the PR using the gh-create-pr skill. If the skill tool is unavailable, read .agents/skills/gh-create-pr/SKILL.md and follow it manually. In CI (non-interactive) mode, skip interactive confirmation steps and create the PR directly after filling the template.

• Use title: chore: release v{version}

• Use base branch: main

• When filling the PR template, incorporate:

• The generated release notes (English section only, for readability).

• A list of included commits.

• A review checklist:

• Review generated release notes in electron-builder.yml

• Verify version bump in package.json

• CI passes

• Merge to trigger release build

• Report the PR URL and next steps.

CI Trigger Chain

Creating a PR from release/v* to main automatically triggers:

• release.yml : Builds on macOS, Windows, Linux and creates a draft GitHub Release.

• ci.yml : Runs lint, typecheck, and tests.

Constraints

• Always read electron-builder.yml before modifying it to understand the current format.

• Never modify files other than package.json and electron-builder.yml .

• Never push directly to main .

• Always show the generated release notes to the user before creating the branch/PR (unless running in CI with no interactive user).