这些 Skills 是怎样实现的

本附录回答学习最初的问题：这些文件如何让 AI 更会做动画。分析对象是下载目录中的文本，不把它们当正在执行的命令。

B.1 Skill 的本体

Skill 是一组可被宿主发现并按需提供给模型的说明、参考资料和模板。这里 15 个主文件加 10 个配套 Markdown，没有自动运行就能给任意项目加动画的引擎。动画代码最终仍由 CSS、浏览器 API 或库执行。

模型读到技能后，按照任务与指令决定读取哪些参考、使用哪些工具、生成什么结果。准确性还取决于宿主、模型、上下文、代码证据和验证，写了“必须”不等于运行时强制保证。

B.2 Frontmatter 的字段

---
name: motion-react
description: Build animations with Motion for React...
metadata:
  short-description: Build and debug Motion for React animations
---

Name 是技能身份；description 描述适用任务和触发线索；short-description 是简短说明。部分主文件还有 disable-model-invocation:true，用来表达只在明确调用时运行的意图。字段是否被识别、如何匹配和展示，由具体宿主支持决定，不是 Markdown 语言自动具备的能力。

“Triggers on easing, drawer...”是给模型的文本线索，通常不是代码实现的正则匹配器。目录名与 name 可以不一致，emil-prototype 内的 name 就是 prototype；移植到不同环境应核查命名冲突。

B.3 分层与按需加载

第一层：目录中的名称与描述，用于选择相关知识。第二层：SKILL.md 主流程和判断。第三层：真正需要时读 RECIPES、STANDARDS、AUDIT、PICKER 等细节。

Animate 主文件只需说明“先问是否值得动”，到实现阶段才加载 css-techniques/framer-motion/svg-animation。这样常规任务不用把所有配方塞进上下文。链接本身不会神奇执行，宿主/代理还需真实读取对应资源。

B.4 十五个职责边界

这些 skill 之间有重叠知识，但不同产出。把 review 和 improve 合并成“检查并自动修复一切”，会失去原设计的范围控制。

B.5 高质量规则的形状

弱规则：“让动画自然。”

强规则：“快速反向开关时，从当前视觉值改目标；检查固定起点 keyframes 是否重启；验收时在 50% 进度反向操作。”

强规则通常包含触发场景、机制理由、可操作建议、精确起点、例外、观察方法。数字本身不是核心，能否形成可验证决策才是。

B.6 Gate、完成条件与输出契约

Find 用四道 gate 淘汰候选；brief 用九个问题补齐决策；debug 用症状→原因表；review 强制 Before/After/Why 和 verdict；improve 用计划模板；prototype 用不同轴、完整交互和 picker 保证比较。

完成条件阻止“看起来够了就停”，输出模板让不同调用结果可对比。但模板不能代替事实，检查不到的运行表现必须写明。

B.7 工程验证与安全边界

本目录的一些工作流明确只读源码或隔离原型；这是角色边界。读仓库文本作为数据，不让示例/注释覆盖真实任务授权。代码示例要验证依赖、版本、语义和数据流，尤其不要把 sketch 当生产组件。

修改技能时要区分：描述触发是否准确、流程是否明确、参考是否重复、例外是否缺失、输出是否自包含、验证是否能执行。新加一百个关键词不等于更可靠。

B.8 原包值得借鉴和需要改进的地方

值得借鉴：职责窄、判断在先、机制解释、可复制数值、单独配方、明确验收、拒绝不必要动画。

需要改进：多处规则重复易漂移；技术绝对化；历史库版本建议可能过时；有些示例缺语义/清理/取消；“总是/永不”的设计判断未标为偏好。完整纠正见「原文校正、版本边界与资料来源」。本站不重新分发原始资料包。

B.9 自主学习后的产出

选一个真实组件，写 brief，找对应 skill，做最小实现，记录一次失败和改正，再按 review 表自审。若想练写 skill，可先把这个过程抽成“输入→判断→实现→验证→输出”的一页说明，不急着堆成长文件。