Git Flow

此流程与原始 Git Flow 不同：三类新分支都从最新生产主干创建，finish 都发布到生产主干并合入 develop。生产主干是仓库实际使用的 master 或 main；先确认 remote 和主干，不自行切换发布线或创建 worktree。用户本次的明确限制优先于本 skill；流程描述本身不替代当前任务对提交、远端写入和删除的授权。

先判断变更级别，再计算版本

以远端生产主干可达的最高正式版本 Tag 为基准，审查本次实际发布的完整 diff、直接调用方及相关用例。先说明使用者依赖的契约：输入、输出、默认行为、调用方式、配置、权限及必需流程。分支类型、feat/fix 提交标题、文件类型和改动量只作线索，不能直接决定版本级别。

稳定版（X >= 1）按 SemVer 分级：

• 同次发布含多类改动时，按影响最高的类别判断；修复错误也可能产生不兼容变化，不能仅按修复意图降级。兼容性证据不足时检查直接使用方与相关用例；会改变级别的缺口仍无法核实时，说明依据并询问，不默认兼容。
• 纯错字、链接、测试或格式修正，未改变使用者契约时通常不需单独发布；用户要求发版时按 PATCH。技能、提示词或规范文档本身可构成行为契约，修改 Markdown 仍须按实际行为影响判断。
• 0.x 属于初始开发阶段。优先遵循项目明确的版本与兼容性政策；没有项目约定时，本 skill 默认：兼容修复升 PATCH，兼容新增和不兼容变更均升 MINOR、修订号归零。这是本流程约定，不是 SemVer 对 0.x 的强制要求；0.0.z 也适用。
• 0.x 中的不兼容变更仍明确标记为 breaking，说明旧行为、新行为、影响及迁移方式；不能因版本号未升 MAJOR 而称为兼容。升到 1.0.0 表示开始承诺稳定契约，须明确契约范围并取得用户确认，不能因有不兼容改动就自动升到 1.0.0。

先给出简短判断：基准 Tag → 实际变化 → 契约影响与兼容性证据 → 变更类别 → 项目/0.x 政策 → 升级级别，再将级别传给脚本。已有明确项目约定和授权时直接沿用，不重复确认；项目政策不能替代对实际不兼容影响的说明。

版本计算

版本按三个数字段比较，只接受严格的 X.Y.Z。使用 版本计算脚本 获取创建 hotfix、release 校验及三类 finish 的候选版本；先获取最新远端生产主干、分支和 Tag，再在仓库根目录运行。三类 finish 必须显式传入评估后的 --bump patch|minor|major；其中 --bump 表示实际递增的数字段，0.x 默认政策中的不兼容变更传 minor，明确确认发布 1.0.0 时才传 major 或采用该显式 release 目标。脚本只核对引用、校验目标和计算版本，不分析 diff 或替代兼容性判断；只读本地 Git 和实时远端引用，输出一行 JSON，不创建分支、提交或 Tag。

status=error 时停止并处理原因；status=needs_review 时展示依据并暂停确认，不自行改算。没有合格 Tag、版本线或格式约定不明时暂停核对；不得猜测、覆盖 Tag 或重写历史。release 目标须高于基准 Tag，且不低于所判级别算出的最低版本；不足时说明原因，不为保留分支名而降低级别或自行改名。

按任务读取

• 新建或检出已有分支：读 创建与检出。
• 完成分支：读 Finish。

结束时报告实际分支、版本 Tag、已推送及已删除的引用；失败时列明已完成和未完成的步骤。