AI Skills
release

release

热门

管理当前项目的版本发布。支持校验变更日志（changelog）、自动安装 git hooks 以及发布新版本。当用户发送“/release”、“release 1.0.5”、“cut a release”或询问发布流程时触发。注意：本 Skill 不会被模型自动调用。

2.9万Star
1779Fork
更新于 2026/6/24
获取 Skill源代码

相关 Skills

camsnap38万fsharp-testing24万tdd-rust8.1万
SKILL.md
只读
名称
release
描述

管理当前项目的版本发布。支持校验变更日志（changelog）、自动安装 git hooks 以及发布新版本。当用户发送“/release”、“release 1.0.5”、“cut a release”或询问发布流程时触发。注意：本 Skill 不会被模型自动调用。

Release

完成版本发布、校验 changelog，并确保已安装 git hooks。

Usage

/release 1.0.5 或 /release patch（在当前版本基础上递增 patch 版本）。

Process

当用户触发 /release <version> 时：

  1. 收集上下文 — 运行 skills/release/scripts/release-context.sh <version>。
    该脚本会静默安装 git hooks，并打印所需的所有信息：版本信息、工作区状态、自上次发布以来的 commit 记录、变更文件、当前 [Unreleased] 内容，以及供格式参考的前一版本日志条目。

  2. 提交未完结的代码 — 如果上下文显示有属于本次发布的已暂存、已修改或未跟踪文件，请先进行提交。可以使用 /commit skill，也可以直接创建规范的 commit。

  3. 编写 Changelog — 如果 [Unreleased] 为空，请根据上下文输出中的 commit 和文件变更记录立即补充。遵循下文的 changelog 规范。如有需要，提交代码后可重新运行 context 脚本。

  4. 切出发布版本 (Cut the release) — 运行 scripts/release.sh <version>。该脚本会将 [Unreleased] 重命名为 [X.Y.Z] - 日期，插入全新的 [Unreleased] 占位，更新 package.json 中的版本号，并完成 commit 和打 tag。

  5. 展示最终 Changelog — 运行 scripts/extract-changelog.sh <version> 打印完整的 [Unreleased] + 次版本号系列汇总。在执行 push 前提示用户确认。

  6. 推送 (Push) — 获得用户明确确认后，运行 git push origin main --tags。

  7. 监控 CI — 推送完成后，发起后台任务监控发布工作流。在 dispatch 模式下使用 interactive_shell 执行：

    gh run watch $(gh run list --workflow=publish.yml --limit=1 --json databaseId --jq '.[0].databaseId') --exit-status

    CI 执行完毕后 Agent 会收到通知并回报结果。

  8. 检查依赖更新 — 在切出发布版本前，检查 sqlite-vec（及平台相关包）、node-llama-cpp 和 better-sqlite3 是否有新版本。运行 pnpm outdated 并回报这些包的可升级信息。如果有可用更新，请直接升级到指定精确版本（锁版本，不使用 ^ 前缀），并在继续前重新运行测试。

若任何步骤失败，请立即停止并说明原因。绝不要强制推送 (force-push) 或跳过校验步骤。

Dependency Policy

所有依赖项必须锁定到精确版本（禁止使用 ^ 或 ~ 等范围前缀）。
Lockfile 确保了安装的可复现性。在添加或更新任何依赖时，务必使用确切的版本号字符串（例如用 "3.18.1" 而不是 "^3.18.1"）。

Changelog Standard

变更日志保存在 CHANGELOG.md 中，遵循 Keep a Changelog 规范。

Heading format

  • ## [Unreleased] — 累计版本间尚未发布的变更条目
  • ## [X.Y.Z] - YYYY-MM-DD — 已发布的版本

Structure of a release entry

每个版本条目由两部分组成：

1. Highlights（亮点摘要，可选，1-4 句话的简述）

紧跟在版本标题下方、任何 ### 章节之前。相当于项目的“电梯演讲”——如果你要在 30 秒内向别人介绍这个版本，你会说什么？仅适用于重要版本；小 patch 版本可直接跳过。

## [1.1.0] - 2026-03-01

QMD 现在支持在 Node.js 和 Bun 上并行运行，通过并行上下文机制将 reranking 速度提升最高 2.7 倍。GPU 自动检测机制已升级，使用显式的 CUDA/Metal/Vulkan 探测替换了原本不太可靠的 `gpu: "auto"`。

2. 详细变更日志（### Changes 与 ### Fixes）

### Changes

- Runtime: support Node.js (>=22) alongside Bun. The `qmd` wrapper
  auto-detects a suitable install via PATH. #149 (thanks @igrigorik)
- Performance: parallel embedding & reranking — up to 2.7x faster on
  multi-core machines.

### Fixes

- Prevent VRAM waste from duplicate context creation during concurrent
  `embedBatch` calls. #152 (thanks @jkrems)

Writing guidelines

  • 解释“为什么”（Why），而不只是“做了什么”（What）。 Changelog 是给用户看的。
  • 附上具体数据。 如“速度提升 2.7 倍”、“内存占用减少 17 倍”。
  • 按主题划分，而不是按文件划分。 比如写“性能优化 (Performance)”，而不是“llm.ts 变更”。
  • 不要列出所有 commit。 汇总关联的变更即可。
  • 致谢贡献者： 对于来自外部社区的 PR，在列表末尾加上 #NNN (thanks @username)。无需为仓库所有者致谢。

What not to include

  • 对用户无感知/无直接影响的内部重构
  • 依赖项版本升级（除非修复了面向用户的 bug）
  • CI/工具链变更（除非影响到了发布产物本身）
  • 新增测试用例（除非是为了验证值得一提的修补）

GitHub Release Notes

每个 GitHub Release 都会包含追溯至 x.x.0 的**次版本号系列 (minor series)**的完整变更日志。scripts/extract-changelog.sh 脚本负责提取此内容，发布工作流 (publish.yml) 会调用它来填充 GitHub Release 说明。

Git Hooks

Pre-push hook (scripts/pre-push) 会拦截带有 v* tag 的推送，除非满足以下条件：

  1. package.json 中的版本号与 tag 匹配
  2. CHANGELOG.md 中包含对应版本的 ## [X.Y.Z] - 日期 条目
  3. GitHub 上的 CI 已经通过（在非交互式 shell 中仅警告，终端中会直接拦截）

Context 脚本会自动静默安装 hooks。你也可以通过 skills/release/scripts/install-hooks.sh 手动安装，或在执行 bun install 时自动安装（prepare 脚本）。