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

1. Get the latest tag:

   git describe --tags --abbrev=0
   

2. Read current version from

   package.json

   .
3. 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

1. List all commits since the last tag:

   git log <last-tag>..HEAD --format="%H %s" --no-merges
   

2. For each commit, get the full body:

   git log <hash> -1 --format="%B"
   

3. Extract the content inside

   ```release-note

   code blocks from each commit body.
4. Extract the conventional commit type from the title (

   feat

   ,

   fix

   ,

   refactor

   ,

   perf

   ,

   docs

   , etc.).
5. 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

1. package.json

   : Update the

   "version"

   field to the new version.

2. 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

1. 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}
   

2. 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
3. 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).