# Release Checklist Skill

> 创建、调整和执行软件发版检查清单 release checklist，尤其关注前端发版、旧业务逻辑稳定性、业务回归、变更影响分析 impact analysis、误发/漏发检查。用于准备发版前检查、发版后验证、go/no-go 判断、hotfix 检查、回滚 rollback 计划、风险评审，以及根据仓库变更判断分支、构建或版本是否可以发布。

- Skill: `cyz7111/release-checklist-skill` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add cyz7111/release-checklist-skill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cyz7111/release-checklist-skill/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cyz7111 (https://skillmd.com/u/cyz7111)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/cyz7111/release-checklist-skill

---


# 发版检查清单

使用这个 skill 生成贴合仓库、产品范围和发版上下文的实用发版检查清单 release checklist。对前端项目，重点关注旧业务逻辑是否稳定、已有用户路径是否被影响、是否误发多余代码，以及是否漏发必要改动。

## 工作流程

1. 只有在无法从上下文推断时，才追问发版目标：
   - 版本、分支、tag、环境、平台或截止时间
   - 发版类型：feature、bugfix、hotfix、rollback、基础设施、依赖升级、移动端、后端、前端、文档或数据迁移
   - 期望输出：检查清单 checklist、go/no-go 结论、风险评审、release notes、rollback plan，或这些内容的组合
   - 前端业务范围：本次需求/缺陷涉及哪些页面、路由、组件、状态流、接口、埋点或权限场景
2. 起草前先检查本地上下文：
   - 阅读已有发版文档、CI 配置、包元信息、changelog、部署脚本、migration 目录和测试命令。
   - 当用户要求针对某次发版检查时，使用 `git status`、`git diff`、近期提交和变更文件来判断风险。
   - 对前端变更，优先查看路由、页面入口、共享组件、hooks、store、API client、权限判断、feature flags、构建配置和样式全局文件。
   - 保留用户已有改动，避免破坏性 git 命令。
3. 围绕真实发版风险构建清单，不输出空泛模板。
4. 区分必须阻断项 blockers 和推荐检查项。
5. 有帮助时补充负责人、证据和可执行命令。
6. 当信息足够时，用简洁的 go/no-go 状态收尾。

## 清单结构

除非用户要求其他格式，优先使用这个结构：

```markdown
## 发版检查清单 Release Checklist

### 阻断项 Blockers
- [ ] 检查项 - 已知负责人/证据/命令

### 必做检查 Required Checks
- [ ] 检查项 - 已知负责人/证据/命令

### 风险评审 Risk Review
- 风险：
- 缓解措施：
- 回滚方案 Rollback：

### 发版后检查 Post-Release
- [ ] 检查项 - 已知负责人/证据/命令

### Go/No-Go
状态：Go | No-go | 信息不足 Needs information
原因：
```

## 常见检查项

只选择与当前发版相关的检查项：

- 源码管理：工作区是否干净、目标分支是否正确、PR 是否已 review、版本 tag、changelog。
- 前端业务稳定性：原有页面路径、核心业务流程、权限分支、异常态、空态、加载态、边界输入是否仍按旧逻辑工作。
- 变更影响分析 impact analysis：变更文件是否影响共享组件、公共 hooks、store、路由守卫、API client、全局样式、构建配置或运行时配置。
- 误发/漏发：是否包含与本次需求无关的代码、调试代码、实验代码、临时开关、console、mock、未完成页面；是否漏掉必要配置、资源文件、接口适配、类型定义、文案或样式。
- 测试：单元测试、集成测试、e2e、smoke test、回归测试、受影响包测试、人工 QA。
- 构建与打包：可复现构建、产物版本、校验和、sourcemap、容器镜像、移动端 build number。
- CI/CD：流水线是否通过、必要审批、部署权限、环境变量、secrets、feature flags。
- 数据库与数据：migrations、backfills、兼容性、rollback 路径、备份、长查询风险。
- API 与兼容性：schema 变化、向后兼容、客户端版本支持、废弃通知。
- 可观测性：dashboard、日志、trace、告警、SLO 影响、错误预算。
- 安全与合规：依赖审计、认证授权变化、PII 处理、许可证影响。
- 发版沟通：release notes、相关方确认、支持团队交接、事故沟通频道。
- 灰度与放量：分阶段发布、canary、feature flag 放量、rollback 条件、on-call 负责人。
- 发版后：smoke check、指标观察、支持队列、后续 ticket。

## 前端业务回归重点

当发版对象是前端项目时，额外执行这些检查：

1. 建立旧业务逻辑基线：
   - 从需求、历史代码、路由、测试用例、线上表现或用户描述中梳理“原来应该怎么工作”。
   - 明确哪些旧路径必须保持不变，哪些行为是本次允许改变的。
2. 做变更影响分析 impact analysis：
   - 将变更文件映射到页面、组件、状态、接口、权限、埋点、样式和构建产物。
   - 标记高风险共享点，例如公共组件、公共 hooks、全局 store、全局 CSS、请求拦截器、路由配置、权限判断。
3. 检查误发：
   - 查找与本次需求无关的文件改动、临时代码、调试日志、mock 数据、隐藏入口、未完成 UI、实验开关和环境配置变更。
   - 如果发现疑似误发，不要直接删除；在清单中标记为 blocker 或待确认，并说明依据。
4. 检查漏发：
   - 对照需求和影响范围，确认页面入口、接口字段、类型定义、资源文件、样式、feature flag、环境变量、文案和测试是否齐全。
   - 如果只看到调用方或只看到被调用方改动，提示可能存在半截变更。
5. 设计回归路径：
   - 覆盖核心旧流程、新增流程、权限差异、异常态、空态、加载态、刷新/返回/重复提交等用户路径。
   - 对共享组件或全局逻辑变更，要求至少列出受影响页面清单。

## 输出规则

- 保持清单具体、可执行。
- 只有在确认命令存在，或项目文件强烈暗示时，才写出精确命令。
- 缺少证据时，将检查项标为 `待确认 Needs verification`，不要假装已经通过。
- 面向用户输出发版结论时，区分“已观察到的事实”和“基于上下文的推断”。
- 高风险发版必须包含 rollback 条件和监控窗口。
- 对前端发版，必须单独输出“旧业务稳定性”“误发风险”“漏发风险”“影响范围”四类结论。