Ship Decision: GO | NO-GO-平芜编程栈

Ship Decision: GO | NO-GO

【免费下载链接】agent-skillsProduction-grade engineering skills for AI coding agents.项目地址: https://gitcode.com/GitHub_Trending/agentskill/agent-skills

Blockers (must fix before ship)

[Source persona: Critical finding + file:line]

Recommended fixes (should fix before ship)

[Source persona: Important finding + file:line]

Acknowledged risks (shipping anyway)

[Risk + mitigation]

Rollback plan

Trigger conditions: [what signals would prompt rollback]
Rollback procedure: [exact steps]
Recovery time objective: [target]

Specialist reports (full)

[code-reviewer report]
[security-auditor report]
[test-engineer report]

模板的结构性含义：每个 Blocker / Recommended fix 必须可溯源到**具体 persona + file:line**；风险要么修复、要么被用户明确接受（写进 Acknowledged risks 并附缓解措施）；回滚方案必须含触发条件、具体步骤、恢复时间目标（RTO）；三份完整人格报告作为裁决的原始证据附在末尾，保证决策可审计。 配套的 **Rules** 五条（文档原文完整继承）： 1. Phase A 的三个人格**必须并行**运行——绝不串行。 2. 人格之间互不调用，合并由主 Agent 在 Phase B 完成。 3. **任何 GO 决策之前，回滚方案是强制项。** 4. 任一人格返回 Critical 发现时，**默认裁决为 NO-GO**，除非用户明确接受该风险。 5. **仅当以下三条同时成立时才允许跳过 fan-out**：变更触及 2 个文件（含）以内、diff 少于 50 行、且不涉及 auth、payments、data access 或 config/env。其余情况默认走 fan-out。文档强调：`/ship` 面向的是生产级变更——当爆炸半径不可忽略时，即使 diff 看起来很小，也要跑并行评审。 第 5 条实质是一条**风险敏感的阈值规则**：不是"diff 小就免检"，而是"diff 小且不碰高风险面才免检"。触碰认证、支付、数据访问或配置的变更，无论行数多少都强制走完整 fan-out。 ### 4.1 与 shipping-and-launch 技能回滚体系的衔接 `/ship` 的回滚要求落在 [skills/shipping-and-launch/SKILL.md](https://link.gitcode.com/i/09d3c6ff19cd94e36d9970e3d6df3bc6) 的完整发布工程框架上。该技能为回滚提供了现成的计划模板（Rollback Strategy 一节），包含： - **Trigger Conditions**：如错误率 > 2x 基线、P95 延迟超阈值、用户报告特定问题； - **Rollback Steps**：关闭 feature flag（如适用）或以 `git revert <commit> && git push` 部署上一版本 → 健康检查与错误监控验证 → 团队通报； - **Database Considerations**：迁移是否有回滚命令、新功能插入的数据是保留还是清理； - **Time to Rollback**：feature flag 回滚 < 1 分钟、重新部署上一版本 < 5 分钟、数据库回滚 < 15 分钟。 同一技能还提供了与 `/ship` 裁决直接配套的分阶段放量机制：staging 全量测试 → 生产部署（flag OFF）→ 团队内启用（24 小时观察窗）→ 5% 金丝雀（24-48 小时，canary 对基线对比）→ 25% → 50% → 100% → 全量放量后一周观察再清理 flag；以及一张"推进 / 暂停调查 / 回滚"三档的量化阈值表（错误率、P95 延迟、客户端 JS 错误、业务指标）。Phase C 输出模板里的 "Trigger conditions" 与 "Recovery time objective" 字段，正是这些阈值的落地位置——`/ship` 产出的是**决策与回滚承诺**，技能提供的是**判定与执行的方法论**。 技能中同样值得注意的两张表可以直接作为 `/ship` 评审的对照物："Common Rationalizations"（如"staging 能跑生产就能跑"→ 生产的数据、流量模式与边界情况不同，部署后必须监控；"回滚是承认失败"→ 回滚是负责任的工程，发布坏功能才是失败）与 "Red Flags"（无回滚计划部署、生产无监控、big-bang 发布、flag 无 owner 无过期时间、部署首小时无人值守、周五下午"顺手发一下"）。 ## 五、设计依据：/ship 是编排目录中的 Pattern 3 [references/orchestration-patterns.md](https://link.gitcode.com/i/e8d7cdba5fd4ba0ee434317da1bea4ce) 是仓库认可的编排模式目录，`/ship` 对应其中的 **Pattern 3：Parallel fan-out with merge**：