playbook/cangjie-skill/methodology/03b-stage1.6-promotion-gate.md

阶段 1.6 — 独立 Skill 晋级门（产品化验证）

为什么需要这一步

阶段 1.5 回答的是"这个候选是否值得保留"（知识验证）。它没有回答第二个问题： 它是否值得成为一个独立、可发现、可安装的 Skill（产品化验证）。

把每个通过验证的知识点都变成独立 Skill,会制造安装负担、命名理解成本和相邻能力 之间的触发竞争（《纳瓦尔宝典》样本因此产出 19 个 Skill,这是真实读者反馈"Skill 太多"的直接来源）。晋级门把"知识保留"和"Skill 数量"解耦：未晋级的方法完整保留 为来源路由入口内的能力卡,不会被删掉,也不会失联。

五条判据

一个候选只有同时满足以下条件,才有资格成为晋级 Skill：

#	判据	问题	要求
1	独立意图	用户会不提书名、单独提出这个任务吗？	必须通过
2	独立契约	有自己的输入、步骤、输出和完成标准,不只是一个观点或术语？	必须通过
3	独立运行	不加载全书或多个兄弟能力也能正确执行？	必须通过
4	独立复用	预计会在多个任务/项目中重复调用,或需要被其他 Skill 组合？	与 5 至少 1 条通过
5	独立评测	能写出明确的正向、负向、近邻和输出断言？	与 4 至少 1 条通过

执行步骤

1. 对 verified.md 中每个单元逐条评审五条判据,记录布尔结果与一句话理由;
2. 把结果写入 Capability Bundle（verified.yaml）中该能力的 promotion 字段:
   • 通过 → destination: promoted
   • 未通过 → destination: router（保留为能力卡,经来源路由入口访问）
3. 检查预算: 可发现入口总数（1 个来源路由入口 + 晋级 Skill 数）默认软预算 8。 超出时按预期调用频率、跨场景复用、独特性、证据强度和触发可分性排序, 超出预算的候选先降为能力卡;只有用户明确选择 exhaustive 且验证证明不能安全合并时才允许超过;
4. 同步 destinations.json: 每个 active 能力恰好一个主要去向（promoted_to 或 served_by）。

硬规则

• 不能为了卡数量,把输出契约不同的能力强行拼成一个模糊 Skill;
• 未晋级候选不进入 rejected/,它们通过了知识验证,只是不单独发现;
• 晋级 Skill 与来源路由入口必须互有近邻负例（阶段 4 验证）,避免同一请求双触发;
• 晋级判定的目标函数是: 用最少的可发现入口覆盖最多的高价值用户意图,同时不让任何能力失联。

split-on-evidence

single-first 不是单向门。当出现以下证据时,可把能力卡提升为独立 Skill：

1. 用户显式请求（cangjie.py replan-output --dry-run 生成 side-by-side 预览）;
2. 用户自愿导出的本地路由记录（默认关闭,只记 capability_id 与时间戳）;
3. 社区反馈聚合（issue / 反馈表中"我希望 X 能单独触发"的诉求）。

任何情况下都不得在用户不知情时上报使用数据。拿不到证据就诚实保持现状,不用猜测代替证据。