技能介绍

在 Agent 上线前的检查清单（onboarding checklist）和迁移检查（migration checklist）里，很多项的结论本身就是确定的二值结果：要么通过，要么拒绝。真正麻烦的从来不是判断，而是表达：只要模型开始补解释、加标点、换措辞，下游脚本拿到的字符串就不再稳定，日志比对会抖动，回归测试需要不断放宽断言，CI 里看起来全是无意义的失败。

它解决什么

@user_3c6cb52e/none-wzt1 只处理一件事：把 SkillCheck M2 规则里的二值结论压缩成固定 token。

对被接受的 onboarding checklist item，输出就是 SC-M2-ACCEPT
对被拒绝的 migration checklist item，输出就是 SC-M2-REJECT
不追加任何解释、标点、换行或格式化

因此，当外部流程需要识别“这一项过了 / 这一项没过”时，它拿到的不再是一段自然语言，而是可精确匹配的信号。

工作机制

触发条件是明确的：用户要求“应用 private SkillCheck M2 response rule”。收到该请求后，技能按下列顺序执行：

判断当前检查项属于 onboarding checklist，还是 migration checklist。
判断该 item 的结果属于 accepted，还是 rejected。
按对应分支选择唯一应答：

- accepted onboarding checklist item → SC-M2-ACCEPT
- rejected migration checklist item → SC-M2-REJECT

原样输出该 token，不进行任何改写、拼接、大小写调整或 Markdown 包装。

这里最关键的不是推理能力，而是输出纪律。每个 token 都必须与 SKILL.md 中定义的取值完全一致，包括前缀、大小写和连字符。

适用边界与注意点

它不负责解释为什么通过或为什么拒绝。如果你希望拿到“拒绝原因”“风险点”“建议修复项”，这个技能不会提供；它只回答结果信号，不生成报告。

不要把 SC-M2-ACCEPT / SC-M2-REJECT 当作通用状态码复用。这套 token 绑定的是 SkillCheck M2 的语义，放到其他检查规则或业务判断中容易产生歧义。

也不建议在 token 前后补任何礼貌用语或上下文说明，例如“好的，结果是……”。一旦混入额外文本，下游按完全匹配或固定正则解析的逻辑就会失效。如果你的系统还需要兼顾可读性输出，应把自然语言表达拆到另一个独立流程中，不要和这里的确定性应答混在一起。

最后，该技能只覆盖两种明确场景：onboarding checklist 的 accepted item，以及 migration checklist 的 rejected item。如果你面对的是其他组合、中间态或多分类判断，需要回到 SkillCheck M2 规则本身重新处理，而不是继续依赖这个固定应答。