菜单
对外发布：在用户明确要求发布、推送或发版时，定版本号、打 tag、推送远端，并按项目实际探测的发布渠道（npm、GitHub Release）发布。每个不可逆对外动作执行前都向用户显式确认。Use when user says release, publish, push, 发版, 发布, 推送, 发包, 打 tag, 升版本, 升级版本号, 发新版本, 上线, 发到 npm, 发 GitHub Release。默认只做用户明确点名的对外动作，不自动扩到全部渠道。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Git 提交：在用户明确要求提交时，轻量安全复核变更、精确暂存、运行相关验证并创建真实 Conventional Commit；只做本地提交，推送与对外发布由 507-release 承接。Use when user says commit, 提交, 提交一下, 提交这些改动, 提交代码, Git 提交, commit 一下, 生成并执行提交, 准备提交, 存个档。
根因修复：已明确存在 bug、报错、崩溃、异常、回归或合并冲突时，先建立可重复反馈环，再以最小改动修复根因并验证。Use when user says fix, 修一下, 修 bug, 报错了, 崩了, 跑挂了, 有 bug, 修复报错, 合并冲突, 修复冲突, 修不通, debugging, error, crash, regression.
维护项目地图：以当前代码为证据，建立或校准 README、doc 组织、目录职责、入口与上下游，只修改地图文档。Use when user says map, project map, 梳理项目结构, 项目结构, 更新 README, 补 README, 校准 README, 整理 doc, 整理结构, 文档地图, 目录职责, 分层 README.
交付审查：围绕明确的 commit、branch、diff 或路径检查 Standards、Spec 与 Code Quality，只报告问题、证据和路由。Use when user says review this change, code review, review 一下, 检查, 审查, 审查改动, 审查这次改动, 检查提交, 检查分支, 过一遍代码, 把关, 需求符合度, 交付审查. 不用于主动寻找全库架构机会。
在保持公开契约与可观察行为不变的前提下，对指定代码范围或 507-inspect 报告逐项建立证据、修改并验证。可深入内部模块、抽象与接缝；若需要行为变化则停止并路由到需求实施。Use when user mentions simplify, simplify code, 简化, 简化代码, 行为不变重构, 内部简化, 按报告修改, 处理 inspect 报告, 局部重构, 降低复杂度, 收敛架构摩擦。
测试任务：测试本身是主要任务时，用现有框架补行为测试、运行测试、修正过时测试或缩小失败范围；真实生产 bug 转根因修复。Use when user says test, testing, 写测试, 加测试, 补测试, 跑测试, 运行测试, 测试挂了, 测试失败, 修失败测试, 缩小失败范围, coverage.
| name | 507-release |
| description | 对外发布：在用户明确要求发布、推送或发版时，定版本号、打 tag、推送远端，并按项目实际探测的发布渠道（npm、GitHub Release）发布。每个不可逆对外动作执行前都向用户显式确认。Use when user says release, publish, push, 发版, 发布, 推送, 发包, 打 tag, 升版本, 升级版本号, 发新版本, 上线, 发到 npm, 发 GitHub Release。默认只做用户明确点名的对外动作，不自动扩到全部渠道。 |
把已完成的本地提交推向外部：定版本号、打 tag、推送远端，并按项目实际探测到的发布渠道发布。它和 507-commit 的分界是可逆性——commit 停在可逆的本地提交，release 才触碰基本不可逆的对外动作（远端、公开包、公开 Release）。
patch / minor / major 或给具体号；用户给出"升一个版本号"这类半模糊指令时，按 semver（语义化版本）原则据 CHANGELOG 变更类型补全具体位；git push --force（强制推送）到主干；507-commit 产出本地提交；本 skill 从"版本号已定、本地提交已就绪"开始。工作区仍有未提交改动时，先回到 507-commit（或相应实现）完成提交，不带着脏工作区发布。
发布前逐项确认，任一不满足则停止并向用户报告：
CHANGELOG.md 的 Unreleased（未发布）段有内容；CHANGELOG 定版段与 tag 三者一致；CHANGELOG 顶部版本段，确认起点版本；Unreleased 内容补全（仅缺陷修复/文档 → patch，向后兼容的新功能 → minor，有 Breaking（破坏性变更）→ major）；CHANGELOG 的 Unreleased 段迁移为 ## [x.y.z] - YYYY-MM-DD，保留段内分类与条目；package.json 的 version）时，同步更新到同一版本号。将版本定版改动（CHANGELOG 迁移、manifest 版本号等）精确暂存，创建一个定版提交，遵循项目既有提交规范。
按项目惯例打 tag，默认 v<x.y.z>（如 v0.2.2），指向定版提交。
向用户显式确认后，把定版提交与 tag 一并推送到远端：
git push origin <branch>
git push origin <x.y.z> # 或 git push origin --tags，按项目惯例
push 被 reject（远端有新提交）时停止，报告冲突，不自动 --force 或 --rebase，交用户处理。
逐个探测项目实际的发布渠道；每个渠道执行前都向用户显式确认。用户没有点名或不同意时跳过该渠道，不静默发布。
package.json；npm publish（预发布版本按项目惯例用 npm publish --tag 打 dist-tag）；gh（GitHub CLI）可用；CHANGELOG 对应版本段提取，不另行编造；gh release create <tag> --notes "..." 创建，预发布版本加 --prerelease。其它发布渠道（容器镜像、二进制产物等）由用户点名时按对应工具执行；本 skill 不预置全部渠道清单。
507-fix；发布前需要交付审查时进入 507-review；发布完成后通常直接结束。