release-testing-workflow

发布测试工作流

中文版本： 请参阅对应的中文技能。

适用场景

• 需要发布窗口节奏：T-N 规划 → 专项测试 → RC → Go/No-Go → 发布后观察。
• 需要发布门禁和发布证据包，并将专项测试执行交由类型技能处理。

决策权限

提供发布建议；正式批准需要由获授权的负责人作出，并记录版本、范围、时间和证据。热修复/金丝雀发布计划可以压缩，但必须保留门禁标准。

工作流

1. 阅读并遵循 prompts/release-testing-workflow.md（时间线、门禁、Go/No-Go、交接）。
2. 补充发布日期、范围、冻结规则、候选构建版本，以及会影响决策的已知缺陷。
3. 确定 T 窗口后，按照 reference.md 中的技能名称进行交接；仅按名称调用专项类型技能。
4. 如果输入不完整，仍需起草门禁看板并标明假设——绝不可编造通过结果。

核心约束

• 负责发布时间线和 Go/No-Go 建议；专项报告交由 performance-testing / security-testing / 等处理。
• 可以压缩时间线，但不得删除门禁标准。
• Go/No-Go 必须有证据支持；有条件的 Go 必须可验证。
• 不得使用指向其他技能文件的相对路径链接。

渐进式披露

• 生成输出前，阅读并遵循 prompts/release-testing-workflow.md。
• 了解步骤 ↔ 交接的映射：阅读 reference.md。
• 深入了解阶段/专项测试：调用匹配的类型技能；不要在此处展开完整专项报告。
• 模板：output-templates/。

交付前检查清单

• 遵循了主提示词的输出结构
• 包含范围/排除项、T 窗口、门禁看板、证据缺口、下一项技能
• 在决策节点给出 Go / No-Go / 有条件的 Go，并说明理由
• 未编造通过结果或未知缺陷状态
• 已标明假设和待解决问题

常见问题

• 不要仅为压缩日程而删除门禁。
• 冻结前不要宣布 RC 完成。
• 不要在此技能中编写完整的专项长报告。
• 不要将有条件的 Go 替换成含糊的“继续观察”。