Skill 全流程构建流水线

要解决什么问题

从零写 Agent Skill 时，常见痛点是：规格写在聊天里、结构与评测口径混在一起、构建者与验收者共享同一上下文，以及「schema 通过」被误当成「行为正确」。skill-creator-max 把自己定位成 指挥者（conductor）：它不亲自写正文、不替你做设计决策，而是按阶段派出全新子代理，只依据各阶段返回的类型化产物（artifact）做门禁与路由。

流水线如何工作

整条链路固定为五类产物，每类对应一个角色包（roles/*.md），并由独立脚本做 L0 结构门禁（通过只表示格式合法，不代表实质正确）：

1. composer → SkillSpec（C 系列 15 字段决策对象），由 scripts/validate_spec 校验
2. guidance → Structure Contract（S 系列单元与分层论证），由 scripts/validate_structure 校验；工程师阶段结束后会 --check-files 再验内容引用是否落盘
3. engineer → Evidence Dossier（E 系列分层评测与校准），由 scripts/validate_report 校验（会重跑 harness）
4. zipper → Compression Report（Z 系列 token 变化与行为等价否决），由 scripts/validate_compression 校验
5. battery → 独立对抗验收（O5/E9：PROVE-OR-FLAG，新鲜上下文、无构建历史泄漏）

调度协议（O6）要求每次派发携带 goal · 输出 schema · 工具/来源 · 边界；同一产物同一时刻只有一个写入者。门禁失败时走 min() 路由（O3）：先假设「最小项」在上游产物字段，把修复预算投到那里，而不是只在报警点打补丁。

高杠杆节点会派出 battery：指挥者需预注册 E9 预算/边际阈值，并植入 seed（每 lens 至少一个）；漏 seed 的 run 作废。最终有效结论为 min(复审计, battery)，可见错误不能算 PASS。指挥者自身还会产出 Decision Record + Learning Record，经 scripts/validate_decision 自门禁。

适用边界

• 仅在用户明确要 author/build/create agent skill 时触发；误触发 token 成本很高。总结记忆、日记、泛化的「创建/总结 X」等属于硬反触发。
• 若意图模糊，应先问一句再派发，不要用整条流水线赌猜测。
• 被构建的技能若含 >1 轮自治循环、工具面/脚本面/持久记忆，Structure Contract 与 Evidence Dossier 有额外分支要求，缺失会导致对应阶段门禁失败。