fileterm: Skill for Codex

FileTerm GitHub Release

目标

把 FileTerm 的版本发布拆成两部分：

1. 自定义正文：版本简介、更新重点、主要 PR/Issue、使用提示和反馈渠道。
2. GitHub 官方生成区：What's Changed、New Contributors、Full Changelog、贡献者头像和贡献者展示。

自定义正文只负责第一部分，绝不能手写或覆盖第二部分。

发布任务所需资料

按正在执行的发布步骤读取：

• docs/quality/git-branch-release-convention.md
• 创建 tag、触发发布或排查流水线时：.github/workflows/release.yml
• 目标版本对应的 docs/release-notes/release-notes-<version>.md（如果已经存在）

以仓库文件为准，不要凭记忆替换发布命令、分支规则或版本同步方式。

执行范围

准备版本说明不等于授权合并、推送 tag 或发布；只执行用户要求的步骤，已有明确授权不重复询问。PR 使用普通 Merge，Issue 只用 Refs / Related to 关联，发布后也须按用户确认保留 Issue 生命周期。

标准流程

1. 在普通分支完成版本说明和版本号

• 功能、修复、文档和版本号改动先进入普通分支并提 PR 到 main。
• 版本号只修改根目录 package.json 的 version 字段。
• 修改后立即运行 npm run sync:version，再检查 workspace 版本和 lockfile。
• 发布说明文件应在合入 main 前进入 PR，并统一放在 docs/release-notes/，例如： docs/release-notes/release-notes-2.2.0-beta.1.md。
• 不要把日常功能改动直接推到 main 或 release/*。

2. 发布说明正文格式

编写或审查发布说明时读取 双语模板与固定格式。保留双语顺序、各自的安装指南徽章、固定标题和逐字反馈块。

3. PR 合入 main

• 提交 PR 后等待所有必需 CI 通过。
• 默认使用 GitHub 普通 Merge（保留 merge commit），不要自行 Squash/Rebase。
• 合并后执行 git fetch origin main，确认 origin/main 包含发布说明和目标版本号。

4. 创建不可变 release 分支和 tag

从最新 origin/main 创建并推送：

VERSION=2.2.0-beta.1
git switch -c "release/$VERSION" origin/main
git push -u origin "release/$VERSION"
git tag -a "v$VERSION" -m "FileTerm v$VERSION"
git push origin "v$VERSION"

约束：

• release/<version> 只保存发布快照，不在上面补正文、修功能或改 workflow。
• tag 必须指向 origin/release/* 分支上的提交，否则 validate-release-tag 会拒绝发布。
• tag 名必须与根版本号、workspace 同步版本和 release notes 文件名一致。
• Beta/RC tag 含预发布后缀，GitHub Release 应显示为 prerelease。

5. 保留 GitHub 官方生成内容

Release title（硬性规则）

GitHub Release 的 Title 必须与 tag 完全一致，只写版本号，例如 tag 为 v2.2.26-beta.3 时，Title 必须是 v2.2.26-beta.3。禁止在前面添加 FileTerm，也不要附加 Release、Beta 或其他说明。此规则只针对 GitHub Release 的 Title 输入框；正文标题仍按上面的双语模板书写。

使用 gh release create 时显式传入 --title "$TAG"。自动发布 workflow 也应把 title 设为当前 tag；发布验收时确认 Release 页面显示的 title 与 tag 完全相同。