Imported from kkyyds-hub/AI-Dev-Orchestrator (.codex/skills/accept-v5-milestone-gate/SKILL.md). Install upstream with npx skills add kkyyds-hub/AI-Dev-Orchestrator --skill accept-v5-milestone-gate. Copyright stays with the author.

accept-v5-milestone-gate

使命与 owner

把 V5 线程里的“现在差不多可以宣布完成了吧”收敛成 诚实、分级、可追责、可继承 的正式裁定。

这个 skill 的 owner 职责只有一个：

负责判断当前最多能宣布到哪一步，并把 gate 结论写成后续线程可直接继承的正式交接物。

它重点负责：

对工作包、单轮切片或阶段给出 Pass / Partial / Blocked / 无法裁定 结论
明确能确认完成的范围、不能确认完成的范围、阻塞原因与遗留项
识别“缺证”和“真阻塞”的区别，避免把信息不足误写成放行或阻塞
判断当前是否具备进入下一线程 / 下一阶段 / 下一层裁定的条件
给 build / write / govern / drive / verify 等兄弟 skill 明确回退或接棒方向

它不应该把线程带偏成：

继续补实现、补验证、补 review 或补 freeze 文档
没有足够材料就乐观放行
把“结构治理完成一部分”写成“前端控制面可宣发”
把“局部切片完成”夸大成“整个 Phase 完成”
不写缺证项、遗留项与下一棒 owner

强绑定的权威输入

优先级从高到低如下：

C:\Users\Administrator\Desktop\AI-Dev-Orchestrator-V5-Plan.md
docs/README.md
C:\Users\Administrator\Desktop\ai-skills草案\00-V5-skill-suite-map.md
C:\Users\Administrator\Desktop\ai-skills草案\accept-v5-milestone-gate-skill-草案.md
references/milestone-gate-map.md
references/pass-partial-blocked-rules.md
references/evidence-requirements-and-rollup-checklist.md
references/milestone-gate-thread-checklist.md
当前工作包的计划 / freeze / 实现说明 / review 结论 / verify 结论 / 文档回填
仅在必要时抽查的相关代码、页面、构建输出、接口响应、日志或脚本输出

如果这些输入之间冲突，以 V5 母本 + 已验证事实 + 已审查风险结论 + 仓库现实为准，不要让乐观叙述覆盖现实。

V5 母本绑定原则

这个 skill 必须明确绑定到 V5 母本，不允许退化成“泛化项目验收”。

默认优先对照母本里的三类验收口径：

产品能力验收

关注：

老板是否真的能配置团队与控制角色
provider / prompt / token / memory / multi-agent 能力是否形成真实闭环
控制面是否只是展示，还是已经能操作、回显并留下事实证据

工程验收

关注：

数据结构、迁移、合同与主链是否闭合
关键路径是否有最小 smoke / integration / build / page / API 证据
结构治理后入口页、锚点、脚本和联调路径是否仍稳定

成本验收

关注：

token / cost 是否有真实统计口径或至少有可追踪基础
成本优化是否只是口号，还是已有量化或可复核证据

如果用户没有指定验收对象，默认先收敛为：

一个工作包或单轮切片
不默认上升为整个 Phase
只有证据闭合时，才允许提升到阶段级裁定

技能边界

什么时候使用

在下列场景使用本 skill：

某个工作包已经过一轮实现、review、verify，想做正式裁定
你想知道当前能否把状态改成“通过 / 部分通过 / 阻塞”
你需要一个正式 gate 结论，给后续线程继承
你需要识别“只是缺证”还是“确实被阻塞”
你要判断“前端结构治理后是否具备放行条件”这类场景

什么时候不要继续停留在本 skill

主任务是修 skill 包本身、修乱码、补 references / templates → build-v5-skill-pack
主任务是写前端控制面、补 hooks / types / api / 页面交互 → write-v5-web-control-surface
主任务是治理 App.tsx / ProjectOverviewPage.tsx、拆分结构、稳定锚点 → govern-v5-web-structure
主任务是跨 backend / web / docs / verify 协调整链交付 → drive-v5-orchestrator-delivery
主任务是查运行事实、build、页面、API、回归 → verify-v5-runtime-and-regression
主任务是做结构风险、合同风险、主链风险审查 → review-v5-code-and-risk
主任务是补 freeze 状态、回填进度与完成定义 → manage-v5-plan-and-freeze-docs

一句话：本 skill 管裁定，不代替实现、治理、验证、总控、文档治理或 skill 维护。

四类正式结论

1. Pass

适用于：

验收对象明确
范围基本闭合
关键实现已完成
必要 review 与 verify 足够支撑当前层级
高风险已消化、已接受或已明确隔离
文档、代码、验证口径一致

2. Partial

适用于：

核心部分完成，但仍有明确缺口
当前可算“切片完成”，不能算“更大范围完成”
可以继续推进，但必须保留遗留项、前置条件与下一棒 owner

3. Blocked

适用于：

验收对象明确，但关键实现、关键依赖或关键风险阻断了放行
存在明确阻塞源：例如 build 失败、入口断裂、接口不通、主链未接通、高风险未解
即使继续讨论，也不能把当前状态写成可放行

4. 无法裁定

适用于：

验收对象不清，甚至不知道在验工作包、切片还是 Phase
缺少必要输入，导致连 Pass / Partial / Blocked 都无法负责任地分级
只有实现自述，没有最小 review / verify / 完成定义支撑
证据之间明显冲突，但还没查清以哪份事实为准

注意：

Blocked = 对象明确，但当前真被事实阻断。
无法裁定 = 连可靠分级基础都不够，先补材料再回来判。

正式落盘边界

本 skill 的主要输出形式

Pass / Partial / Blocked / 无法裁定 结论
验收对象与裁定层级
依据材料与证据等级
能确认完成与不能确认完成的范围
缺证项、阻塞项、遗留项与前置条件
下一线程建议 skill 与理由

默认会触达的材料

母本 / plan / freeze / 回填文档
当前工作包的实现说明
最近一轮 review-v5-code-and-risk 结论
最近一轮 verify-v5-runtime-and-regression 结论
必要时的代码、页面、build、日志、API、脚本现实核对

默认不越权的面

不替实现 skill 修功能
不替 verify 补运行事实
不替 review 做结构 / 合同 / 主链风险识别
不替 manage 直接改冻结状态
不替 build-v5-skill-pack 维护其他 skill 本体

开始入口

每次接手 V5 裁定任务时，先按下面顺序读取，且只读最小集合：

打开 V5 母本：C:\Users\Administrator\Desktop\AI-Dev-Orchestrator-V5-Plan.md
打开 skill map：C:\Users\Administrator\Desktop\ai-skills草案\00-V5-skill-suite-map.md
打开本 skill 自带参考：
- references/milestone-gate-map.md
- references/pass-partial-blocked-rules.md
- references/evidence-requirements-and-rollup-checklist.md
- references/milestone-gate-thread-checklist.md
打开当前工作包的计划 / freeze / 回填文档
打开最近一轮 review-v5-code-and-risk 结论
打开最近一轮 verify-v5-runtime-and-regression 结论
只在必要时抽查最相关的代码、页面或输出事实

最小必读材料

当前工作包或阶段的完成定义
最近一轮实现说明
最近一轮 review 结论
最近一轮 verify 结论
若已有 freeze 回填，则同步查看其状态口径

按验收对象补读

工作包 / 切片级验收

该切片直接改动的代码或页面入口
与当前切片直接相关的 verify 证据
相关 review 风险分级

阶段级验收

该 Phase 下多个工作包的回填
build / smoke / page / API 证据汇总
关键遗留项与前置条件清单

如何处理模糊请求

遇到“现在能不能算完成”“能不能过这阶段”“给个正式结论”这类模糊请求时：

先翻译成 一个验收对象 + 一个裁定层级。
默认先验收工作包或切片，不默认直接验收整个 Phase。
明确这次结论影响哪个状态口径。
如果材料不足，也要把“当前只能给无法裁定 / Partial / Blocked”写成结论的一部分。

例如：

“Phase 1 现在能过吗” → 先拆成 provider / prompt / token / role policy / memory recall 各自是否闭合
“这轮 runtime 改动能不能算完成” → 先按单轮后端切片做裁定，不直接上升到整个模块
“这个团队控制中心能不能宣发” → 先看前端控制面、后端合同、verify 证据与遗留风险是否闭合
“前端结构治理后能不能放行” → 先看治理范围、入口 / build / 锚点 / 脚本 / 回归证据与遗留结构债是否闭合

核心工作流

1. 先判 owner 是否正确

先回答：

当前主任务真的是“裁定”，还是其实还在补实现 / 补验证 / 修 skill？
当前对象是一个切片、一个工作包，还是整个 Phase？
如果现在继续做 accept，会不会越权替别人补事实？

判错 owner，就会把整个结论写偏。

2. 锁定验收对象与裁定层级

至少写清：

Phase
工作包 / 切片
本轮只裁定什么
本轮明确不裁定什么

3. 收齐三类材料

尽量同时看三类材料：

完成定义与计划口径
实现与 review 风险材料
verify 与运行证据

少任意一类，结论都容易失真；必要时直接进入“无法裁定”。

4. 区分“缺证”与“真阻塞”

优先判断：

是不是材料不够，所以还不能分级？→ 无法裁定
还是对象明确，但已被 build / 入口 / 合同 / 主链 / 高风险事实卡住？→ Blocked

5. 判断“最多能说到哪里”

验收不是追求积极，而是追求准确。

如果当前最多只能说：

“结构治理切片已完成，入口与 build 最小回归通过”

就不要写成：

“整个前端控制面可宣发”

6. 套用分级规则

满足闭合条件 → Pass
仅切片闭合、仍有明确缺口 → Partial
有明确事实阻塞 → Blocked
缺材料或材料冲突到无法负责任分级 → 无法裁定

7. 写正式遗留项

每次裁定至少留下：

风险
缺证项
必补项
下一阶段前置条件
下一线程建议 owner

8. 明确交接路线

线程结束时必须明确下一棒是谁：

若完成定义不清 → manage-v5-plan-and-freeze-docs
若实现不够 → write-v5-runtime-backend / write-v5-web-control-surface
若结构治理未闭合 → govern-v5-web-structure
若缺运行事实 / build / 页面 / 回归证据 → verify-v5-runtime-and-regression
若高风险没澄清 → review-v5-code-and-risk
若本质是跨层整链收口 → drive-v5-orchestrator-delivery
若要修 accept skill 包本身 → build-v5-skill-pack

特别场景：前端结构治理后是否具备放行条件

这是本 skill 的高频 gate 场景之一，但要和 govern-v5-web-structure、verify-v5-runtime-and-regression 分工清楚。

`govern-v5-web-structure` 负责什么

做结构治理方案与落地
控制入口页瘦身、拆分边界、测试锚点规范
说明联调影响与最小验证建议

`verify-v5-runtime-and-regression` 负责什么

证明 build、入口、页面、脚本、锚点或回归事实是否成立
记录失败事实、环境阻塞与证据等级