用途：用 GitHub issue 作为发布前生产侧待办清单，随开发进展持续维护。需从请求、仓库说明或对话中确定目标仓库、issue 编号、非生产环境、生产环境与发布路径；若仓库或 issue 不明确，应先询问再改动。
核心规则：只有某项能力已在相关非生产环境可运行，才添加其生产对应步骤。该 issue 不是愿望清单；若用户要求为尚未在非生产环境工作的功能添加步骤，应先确认。
结构：按阶段组织，新增步骤放入正确阶段。阶段1 基础设施：数据库、存储、域名、密钥、环境配置、外部服务的生产对应项；阶段2 应用就绪：功能与验证如 lint、typecheck、集成测试、端到端测试；阶段3 发布前冒烟测试：对指定非生产部署手动检查；阶段4 发布：发布 PR 或等效晋级、CI、合并、生产部署、迁移等；阶段5 发布后验证：对生产域名检查。另含“生产环境变量总表”。新增集成引入变量或密钥时，同时在相关阶段与环境变量表添加。
工作流：先了解非生产环境外发生了什么、确认其在非生产环境可用，判断需要生产变量/密钥、手动步骤、发布动作还是验证步骤及涉及阶段。读取当前 issue 正文： gh issue view <issue-number> --repo <owner/repo> --json title,body,url 按现有风格插入步骤：用 - [ ] 复选框；措辞为具体可验证的生产动作（如 SERVICE_API_KEY set in the production environment）；必要时用反引号引用文件名和配置名；同步更新环境变量表；避免重复。写回时保留原有内容，仅增改，使用 heredoc 保持格式： gh issue edit <issue-number> --repo <owner/repo> --body "$(cat <<'BODY' <full updated issue body> BODY )" 最后告知新增内容及阶段并返回 issue URL。
风格与限制：保持简洁、面向生产；不把仅属非生产的事项写为生产步骤；避免“审查计划/连接限制”等模糊项；沿用现有清单的简练祈使语气；只修改指定发布 issue，未经明确要求不动其他 issue 或推送代码。