准备生产发布、切版本或部署前…

适用于任何生产发布前，需要系统性完成安全审计、E2E 测试、最终评审、版本升级和发布说明的场景。

适用场景

解决思路

1. 按顺序调用 5 个代理链：aegis → atlas → review-agent → herald → scribe，依次产出安全审计 → E2E 测试 → 最终评审 → 版本升级/CHANGELOG → 发布说明/文档。
2. Phase 1 安全审计：调用 `Task(subagent_type=aegis)`，提示为 `Security audit for release: [VERSION]`；扫描依赖漏洞（`npm audit`、`pip audit`）、硬编码密钥/凭据、SQL 注入/XSS/CSRF 风险、认证/授权问题、不安全配置；输出带严重级别的安全报告。
3. Phase 2 E2E 测试：调用 `Task(subagent_type=atlas)`，提示为 `Run E2E tests for release: [VERSION]`；执行完整 E2E 测试套件、关键路径测试、集成测试、性能基准（如适用）；输出含 pass/fail 计数的测试报告。
4. Phase 3 最终评审：调用 `Task(subagent_type=review-agent)`，提示为 `Final release review: [VERSION]`；检查安全审计结果、E2E 测试结果、自上次发布以来的变更（`git log`）、破坏性变更、迁移要求；输出 `RELEASE_APPROVED` 或 `RELEASE_BLOCKED` 及原因。
5. Phase 4 版本升级与 CHANGELOG：调用 `Task(subagent_type=herald)`，提示为 `Prepare release: [VERSION]`；在 `package.json`/`pyproject.toml` 中升级版本、生成 `CHANGELOG.md` 条目、更新代码中的版本常量、为提交打 tag（先不要 push）；遵循语义化版本。
6. Phase 5 发布说明：调用 `Task(subagent_type=scribe)`，提示为 `Write release notes: [VERSION]`；包含变更摘要、新功能、Bug 修复、破坏性变更、迁移指南（如需要）、贡献者；输出 `RELEASE.md` 或更新 docs。
7. 确保执行顺序理由：安全优先，在发布前捕获漏洞；E2E 测试验证系统端到端可用；最终评审提供 human-in-the-loop 批准；仅在批准后才升级版本；随发布提供正式发布说明。
8. Major Release（破坏性变更）：使用 `/release --major`，执行完整工作流并包含迁移指南。
9. Minor Release（新功能）：使用 `/release --minor`，执行完整工作流，安全审查较轻。
10. Patch Release（Bug 修复）：使用 `/release --patch`，执行安全 + 测试 + 快速评审。
11. Hotfix：使用 `/release --hotfix`，走加急路径 aegis → atlas → herald。
12. 阻断规则：发现严重安全漏洞、E2E 测试失败、或评审结论为 `RELEASE_BLOCKED` 时，停止工作流并先修复关键问题（例如 `user.py:45` 的 SQL 注入）。
13. Flags：`--major`/`--minor`/`--patch` 指定语义版本类型；`--hotfix` 走加急发布路径；`--skip-security` 跳过安全审计（不推荐）；`--dry-run` 只运行检查而不升级版本。
14. 发布就绪后的后续动作：`git push origin vX.Y.Z`、创建 GitHub release、部署到生产环境。
15. 确认发布就绪输出：安全无严重漏洞且低危已记录；E2E 全部通过（如 156/156）；评审为 `RELEASE_APPROVED`；版本已升级；`CHANGELOG.md` 已更新；git tag 已创建；`RELEASE-vX.Y.Z.md` 已生成。

适用边界 · 注意事项

• 发现严重安全漏洞、E2E 测试失败或评审返回 `RELEASE_BLOCKED` 时，不应继续发布。
• 不推荐使用 `--skip-security`；除紧急 hotfix 外，不要省略最终评审与发布说明。
• 非生产发布、无需版本化和发布说明的日常改动，不适合套用完整 `/release` 流程。