Préparer la Publication

Automatiser le workflow de publication de Cherry Studio : collecter les modifications → générer les notes de publication bilingues → mettre à jour les fichiers → créer la branche de publication + PR → déclencher CI/CD.

Arguments

Analyser l'intention de version à partir du message de l'utilisateur. Accepter l'une de ces formes :

Mot-clé de bump : patch, minor, major
Version exacte : x.y.z ou x.y.z-pre.N (par ex. 1.8.0, 1.8.0-beta.1, 1.8.0-rc.1)
Langage naturel : "prepare a beta release", "bump to 1.8.0-rc.2", etc.

Par défaut patch si aucune version n'est spécifiée. Toujours confirmer la version cible résolue à l'utilisateur avant de procéder à des modifications de fichiers.

--dry-run : Aperçu uniquement, ne pas créer de branche ou de PR.

Workflow

Étape 1 : Déterminer la Version

Récupérer le dernier tag :
```
git describe --tags --abbrev=0
```
Lire la version actuelle depuis package.json.
Calculer la nouvelle version en fonction de l'argument :
- patch / minor / major : bump à partir de la version du dernier tag.
- x.y.z ou x.y.z-pre.N : utiliser tel quel après validation du semver.

Étape 2 : Collecter les Commits

Lister tous les commits depuis le dernier tag :

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

Pour chaque commit, récupérer le corps complet :
```
git log <hash> -1 --format="%B"
```
Extraire le contenu à l'intérieur des blocs de code ```release-note de chaque corps de commit.
Extraire le type de conventional commit du titre (feat, fix, refactor, perf, docs, etc.).
Ignorer ces commits :
- Titres commençant par 🤖 Daily Auto I18N
- Titres commençant par Merge
- Titres commençant par chore(deps)
- Titres commençant par chore: release
- Commits où le bloc release-note dit NONE

Étape 3 : Générer les Notes de Publication Bilingues

À partir des informations de commit collectées, générer les notes de publication en anglais et en chinois.

Format (doit correspondre exactement) :

<!--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-->

Règles :

Inclure uniquement les catégories ayant des entrées (omettre les catégories vides).
Chaque commit apparaît comme exactement UNE ligne dans la catégorie appropriée.
Utiliser le champ release-note s'il est présent ; sinon résumer à partir du titre du commit.
Les tags de composant doivent être courts : [Chat], [Models], [Agent], [MCP], [Settings], [Data], [Build], etc.
Les traductions chinoises doivent être naturelles, pas littérales.
NE PAS inclure de hashs de commit ou de numéros de PR.
Lire les notes de publication existantes dans electron-builder.yml comme référence de style avant d'écrire.

IMPORTANT : Contenu Orienté Utilisateur Uniquement

Les notes de publication sont pour les utilisateurs finaux, pas pour les développeurs. Exclure tout ce qui ne préoccupe pas les utilisateurs :

EXCLURE les refactorisations internes, le nettoyage de code ou les changements d'architecture
EXCLURE les changements CI/CD, les outils de build ou l'infrastructure de test
EXCLURE les mises à jour de dépendances (sauf si elles ajoutent des fonctionnalités visibles)
EXCLURE les mises à jour de documentation
EXCLURE les améliorations de l'expérience développeur
EXCLURE les corrections de dette technique sans impact visible
EXCLURE les descriptions trop techniques (par ex. "fix race condition in Redux middleware")

INCLURE uniquement les changements que les utilisateurs remarqueront :

Les nouvelles fonctionnalités qu'ils peuvent utiliser
Les corrections de bugs qui affectaient leur workflow
Les améliorations UI/UX qu'ils peuvent voir
Les améliorations de performance qu'ils peuvent ressentir
Les correctifs de sécurité (simplifiés, sans détails d'implémentation)

Garder les descriptions simples et non-techniques :

❌ "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"

Étape 4 : Mettre à Jour les Fichiers

package.json : Mettre à jour le champ "version" à la nouvelle version.
electron-builder.yml : Remplacer le contenu sous releaseInfo.releaseNotes: | par les notes générées. Préserver l'indentation YAML de 4 espaces pour le contenu du bloc scalaire.

Étape 5 : Présenter pour Révision

Montrer à l'utilisateur :

Le nouveau numéro de version.
Les notes de publication générées complètes.
Un résumé des fichiers modifiés.

Si --dry-run était spécifié, s'arrêter ici.

Sinon, demander à l'utilisateur de confirmer avant de procéder à l'Étape 6.

Étape 6 : Créer la Branche et la PR

Créer et pousser la branche de publication :

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}

Créer la PR en utilisant le skill gh-create-pr. Si le skill n'est pas disponible, lire .agents/skills/gh-create-pr/SKILL.md et suivre manuellement. En mode CI (non-interactif), ignorer les étapes de confirmation interactive et créer la PR directement après remplissage du template.
- Utiliser le titre : chore: release v{version}
- Utiliser la branche de base : main
- Lors du remplissage du template de PR, incorporer :
  - Les notes de publication générées (section anglaise uniquement, pour la lisibilité).
  - Une liste des commits inclus.
  - Une checklist de révision :
    - [ ] Review generated release notes in electron-builder.yml
    - [ ] Verify version bump in package.json
    - [ ] CI passes
    - [ ] Merge to trigger release build
Signaler l'URL de la PR et les prochaines étapes.

Chaîne de Déclenchement CI

Créer une PR de release/v* vers main déclenche automatiquement :

release.yml : Construit sur macOS, Windows, Linux et crée une GitHub Release en brouillon.
ci.yml : Exécute lint, typecheck et tests.

Contraintes

Toujours lire electron-builder.yml avant le modifier pour comprendre le format actuel.
Ne jamais modifier d'autres fichiers que package.json et electron-builder.yml.
Ne jamais pousser directement sur main.
Toujours montrer les notes de publication générées à l'utilisateur avant de créer la branche/PR (sauf en CI sans utilisateur interactif).

prepare-release