docs: add factory release skill

.agents/skills/release/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: factory-release
+description: Use when the user explicitly asks to release the factory backend, run its release workflow, or bump its deployed version.
+---
+
+# 发布 Factory 后端
+
+仅在用户明确要求后端发版、release 或提升部署版本时执行本流程。普通代码修改、提交或推送不触发发版。
+
+严格按以下顺序执行：
+
+1. 确认目标是当前 `factory` 后端。若用户要求发布 `ehs_web` 前端，改读 `.codex/memory/reference_ehs_web_release.md`。
+2. 执行 `git status --short`，确认工作区状态。发布提交只能包含 `changelog.md` 和 `server/settings.py`；不得混入其他已修改或未跟踪文件。
+3. 执行 `bash update_changelog.sh`，从脚本输出读取形如 `3.1.YYYYMMDDHH` 的版本号，记为 `<VER>`。不得自行编造或改写版本号。
+4. 把 `server/settings.py` 中唯一权威版本字段 `SYS_VERSION` 更新为 `<VER>`。
+5. 读取 `changelog.md` 顶部约 20 行，确认标题是 `## <VER>`，且自上一个 tag 起的提交分类合理。出现重复段、明显漏项或无关内容时，先向用户确认，不得继续打 tag。
+6. 再次检查 diff，只暂存 `changelog.md` 和 `server/settings.py`。
+7. 提交信息使用 `release: <VER>`，不添加工具或模型专属署名。
+8. 创建无 `v` 前缀的 tag：`git tag <VER>`。
+9. 推送当前分支到 `origin`，成功后再执行 `git push origin <VER>`。逐步检查结果，不用命令链掩盖中间失败。
+10. 汇报 `<VER>`、changelog 包含的提交类别、commit hash、tag 名，以及分支和 tag 的推送结果。
+
+若提交、tag 或推送中途失败，先检查实际 Git 状态。任何会重写历史或删除远端 tag 的回退操作，都必须先取得用户明确授权。