soia-dev-release-plan-checklist

为互联网软件交付生成可执行、可核对的发布清单。输入是发布范围和已知约束，输出是待确认项明确的发布计划；它不执行部署、修改生产环境或代替发布审批。

范围：本技能处理软件发版（代码、服务、客户端或基础设施交付）。文章、社媒、视频等内容发布不在范围内，请使用 media 域的内容发布技能。

客户可读说明

这个技能可以做什么

提供发布目标、版本/分支、环境、变更和服务依赖；信息不全时也可先产出带待确认项的草案。

客户如何使用

用自然语言说明发布目标，并尽量提供：服务或产品、目标环境、版本与源分支、制品标识、配置变更、依赖服务、期望窗口、审批人和回滚方案。可用下面的最小输入：

release:
  product_or_service: <服务或产品>
  environment: <staging|production>
  version: <版本或提交标识>
  source_branch: <分支>
  artifact: <镜像、包或构建产物标识>
  config_changes: [<变更或无>]
  dependencies: [<依赖服务>]
  release_window: <时间窗口或待定>

未知信息必须标为“待确认”，不能由 Agent 猜成既定事实。客户确认清单后，按其既有发布平台和权限执行；本技能本身不发布。

依赖与安装

这是纯方法论技能，无强依赖、可选增强或第三方工具依赖，也无需创建私有配置。

claude plugin marketplace add soia-team/soia-open-skills

claude plugin install soia-dev@soia

只要这一个技能时，可用 npx 路线。注意技能会落进共享真源 ~/.agents/skills；若同时装了插件，同一技能会出现两份索引且各自漂移，建议二选一：

npx skills add soia-team/soia-open-dev-skills -g -a '*' -s soia-dev-release-plan-checklist -y

配置约定采用 schema v2；如客户需要保存团队默认项，可在其自有机器创建下列文件，未创建时按请求中的输入工作：

~/.config/soia-skills/soia-dev-release-plan-checklist/config.yml

不要在配置或交付物中记录凭据、令牌、内部地址或真实客户数据。

工作流程

1. 确认边界。 识别这是软件发版而非内容发布；确认目标、环境、窗口、负责人和是否只生成计划。若请求实际为内容发布，说明应转至 media 域并停止本流程。
2. 建立发布基线。 列出版本、源分支或提交、制品及其来源、目标环境、数据库或配置变更、依赖服务和兼容性假设。缺失项写入待确认区。
3. 生成预检门。 对每项给出责任角色、证据和阻断规则：构建制品可追溯、自动/手工测试通过、变更评审与审批完成、依赖健康、容量与监控就绪、回滚制品和步骤可用。没有证据的门不得标为通过。
4. 设计发布与灰度。 按客户的发布机制定义批次、每批覆盖范围、观察时长、核心成功指标、错误预算或停止阈值，以及暂停、回滚和升级负责人。没有阈值时标“待确认”，不虚构数值。
5. 编排验证。 给出发布前冒烟检查、每批灰度验证、全量切换确认，以及发布后功能、性能、错误率、告警、数据完整性和依赖链路检查。每项注明检查方法或证据来源。
6. 复核可执行性。 检查版本、分支、制品、配置、依赖、审批和回滚之间是否对应；特别检查配置/数据库变更的前后兼容与回滚可行性。
7. 交付并保留决策点。 输出清单、预检状态、灰度/验证步骤和未决项。只有客户明确授权且所有相关门通过，才可建议进入实际发布流程。

输出契约

输出为 Markdown 发布清单，固定包含以下部分：

1. 发布摘要： 范围、环境、窗口、版本、分支、制品、负责人，以及“软件发版”范围声明。
2. 变更与依赖清单： 代码/制品、配置、数据或迁移、依赖服务、兼容性与待确认项；每项有状态（已知/待确认/不适用）。
3. 预检门： 测试、审批、可观测性、依赖健康、回滚预案等，列出责任角色、证据、通过条件和阻断条件。
4. 灰度与发布步骤： 顺序、批次/范围、观察项、通过阈值或待确认值、停止/回滚动作与负责人。
5. 发布后验证清单： 冒烟、业务关键路径、错误与延迟、容量、告警、数据一致性、依赖服务和客户反馈入口。
6. 结论与未决项： 可进入下一阶段、阻断发布或仅供评审的结论；不得把待确认项表述为已通过。

默认使用虚构占位符，例如 <服务A>、<版本>、<制品标识>。没有实际证据时，输出“未验证”及取得证据的下一步。

私密信息与中间数据

• 仅使用客户在当前请求中主动提供的发布信息；不读取公司知识库、私有仓库、账号、历史发布记录或本地私密配置来补全清单。
• 不要求、记录或回显密钥、令牌、密码、会话、客户数据、内部域名或生产访问地址。若输入含此类值，改为 <已提供的敏感值>。
• 计划草案和推理中的中间信息仅用于当前会话；客户若要求落盘，应自行选择受控位置与保留期，并先脱敏。

日志与完成回执

最终回复必须给出：

• 已覆盖的发布要素（版本、分支、制品、配置、依赖、测试、审批、回滚、灰度、发布后验证）；
• 预检门状态数量（通过、阻断、待确认）及每个阻断或待确认的原因；
• 已使用的证据与未实际验证的项目；
• 建议的下一步，例如补齐制品校验、确认停止阈值或取得审批。

不要将“已生成清单”说成“已经发布”或“已验证生产环境”。

验收

在交付前进行一次前向检查：从输出中任选一个灰度批次，确认它同时含有范围、观察项、通过条件或待确认标记、停止动作和负责人；并确认每个预检门都有证据或明确的缺口。缺一项则回到相应流程步骤补全。

WorkBuddy 的装载单位是角色化专家而不是插件，npx skills add -a '*' 覆盖不到它，需要单独安装，见 docs/install/workbuddy.md。