releasing

用途

该技能用于将 @jkudish/jev-mcp 包发布到 npm 和 GitHub。适用于发布新版本、更新版本号、编写变更日志、发布到 npm、打标签等场景。

发布流程

发布有两个目标（npm 与 GitHub）和一个审批关卡。智能体负责暂存 npm 发布，只有 Joey 可以通过通行密钥在 npmjs.com 的 Staged Packages 标签页批准。其余步骤均为机械且精确的操作。

具体顺序如下：

1. 在 package.json 中更新版本号。在 CHANGELOG.md 中添加 ## <version> 段落，仅包含用户可见的变更，不包含内部任务 ID 或私有名称。
2. 同步锁文件：npm install --package-lock-only。package.json 与 package-lock 之间的名称或版本不匹配会导致 CI 中的 npm ci 失败。
3. 提交、推送并等待 CI 通过。不要在构建失败的情况下发布。
4. 暂存 npm 发布：npx npm@latest stage publish。记录暂存的版本和 shasum。暂存使用配置的 NPM_TOKEN 凭据，无需 2FA。
5. 停止。请 Joey 在 npmjs.com（Staged Packages 标签页，通行密钥）批准暂存的包。这是人工关卡，未经批准不会发布任何内容。
6. 批准后，对第 4 步中打包的确切提交打标签，而不是可能已移动的 HEAD：git tag -a v<version> <sha> -m "v<version>: summary"，然后 git push origin v<version>。
7. 从该标签创建 GitHub 发布，使用变更日志段落作为说明，并附上安装命令 npx -y @jkudish/jev-mcp。
8. 验证：npm view @jkudish/jev-mcp version --prefer-online 返回新版本，且发布页面正常渲染。

规则与陷阱

• 暂存发布无法创建全新包。任何新包的第一个版本必须由 Joey 使用 npx npm@latest publish（浏览器通行密钥）交互式发布。之后的所有版本均可暂存。
• 批准后注册表传播大约滞后 5 到 10 分钟。发布后立即从 npm view 或 npx 收到 404 是传播延迟，而非故障。
• npx 会缓存失败的解析结果。在传播窗口之后，删除 ~/.npm/_npx 再判断包是否损坏。
• 标签、tarball 和注册表版本必须逐字节一致。暂存后落地的文档将在下一个版本中发布；对已发布版本重新打标签永远不正确。
• npm 包的 README 来自暂存时的 tarball，而非 GitHub HEAD。
• 永远不要重新发布注册表中已存在的版本。

验证清单

• 发布提交上 CI 通过。
• npx npm@latest stage list 显示了暂存的版本和 shasum。
• Joey 已批准；npm view @jkudish/jev-mcp version --prefer-online 返回该版本。
• 标签指向打包的 sha，且 GitHub 发布存在于该标签上。

限制

暂未提供关于收费、价格、平台支持范围或效果保证的信息。

仓库：https://github.com/jkudish/jev-mcp