release-checklisted

# release-check 对实现结果、QA 验收、运行环境和发布对象做发布前只读检查，输出发布建议、风险和回滚条件；该 skill 只给出发布建议，不执行真实发布、部署、推送或外部系统变更。 ## 用法 `/release-check <发布对象、实现结果、QA 证据或环境信息>` ## 目标 - 汇总发布对象、验证证据和环境前置条件 - 检查发布前风险、监控关注点和回滚条件是否明确 - 给出 `ready` / `needs-info` / `not-ready` 的发布建议 - 明确哪些动作需要人工确认或单独发布命令执行 ## 适用场景 - 代码、文档、配置或脚本准备发布前需要最终检查 - QA 已给出结论，需要确认运行验证和回滚条件 - 变更涉及环境、部署、监控、上传或外部系统副作用 - 发布前需要整理人工确认清单 ## 不适用场景 - 执行真实发布、部署、推送、上传或回滚 - 绕过 QA 验收或替代 `/acceptance-check` - 对没有发布对象或环境信息的任务强行给出 ready - 修改代码、配置、CI/CD 或基础设施 ## 发布检查模板 发布检查字段必须与 [docs/claude/standards.md](../../../docs/claude/standards.md) 中“发布检查应至少包含”的要求一致： 1. **发布对象**：明确发布内容、版本、目标环境、影响范围和是否涉及外部系统。 2. **发布前检查项**：列出 QA 结论、测试命令、配置检查、权限检查、数据/迁移检查和依赖状态。 3. **运行验证方式**：说明发布后如何验证关键路径，包括命令、页面、接口、日志或 artifact 检查方式。 4. **监控关注点**：列出发布后需要观察的错误率、耗时、资源、日志、告警或业务指标。 5. **回滚条件**：定义触发回滚的失败信号、回滚入口、需要保留的证据和人工确认人。 6. **发布结论**：只能是 `ready`、`needs-info` 或 `not-ready`，并给出一句理由。 ## 结论规则 - `ready`：QA 已通过，发布前检查项满足，运行验证方式和回滚条件明确，且无未处理高风险。 - `needs-info`：缺少环境、QA 证据、验证方式、监控或回滚条件，无法判断是否可发布。 - `not-ready`：存在失败测试、阻塞缺陷、未批准危险操作、不可接受风险或缺失必要人工确认。 ## 风险边界 - 涉及 git push、上传、部署、迁移、删除、回滚或修改共享基础设施时，必须标记需要人工确认。 - 只有检查结果，不代表真实发布已经完成。 - 若发布对象只是文档或本地配置，也必须说明如何验证用户能找到并理解变更。 ## 执行规则 1. 只读取用户提供的实现结果、QA 证据、环境信息和发布对象。 2. 不执行发布命令，不推送代码，不修改远端系统，不创建外部副作用。 3. 缺少 QA 通过证据、运行验证方式或回滚条件时，结论不得为 `ready`。 4. 发布对象涉及危险操作时，必须列出人工确认节点。 5. 输出必须区分“检查建议”和“真实发布动作”，避免用户误以为已发布。 ## 示例 - `/release-check v0.8 文档与 skill 变更，基于 QA 验收记录判断是否可发布` - `/release-check upload_to_github.sh 发布前检查，重点确认人工确认节点和回滚条件` - `/release-c