经验沉淀自
智能体在为某一处动效挑选配料时常常选错：本该用 ease-out 的入场，却配了 ease-in；本该用半透明阴影建立层级，却给了一圈实色描边。
这些细节会不断累积，最后决定你的界面是惊艳，还是平平无奇。下面三处是最常见的错法，右边是同一件事的另一种做法。
阅读总纲里的规则层级
界面靠什么表达前后关系
一圈同样深的灰线，所有元素平铺在同一层。
阴影带出高度差，边界自然，深色模式下也成立。
时长
位移越大，越需要时间
同样一段长距离，快到来不及看清就结束。
按距离定时长，眼睛跟得上，也不拖沓。
属性
动什么，比动多久更关键
动画布局属性，掉帧就从这里开始。
只动 transform 与 opacity，视觉更稳。
去学编程、学设计，或在任何其他领域沉淀专业能力吧。AI 不会取代这种专业能力，它只会放大你能从中获得的成果。
Emil Kowalski · skills 作者
共 13 个
它们合起来覆盖了从立意、构建、审查到收尾的整条链路。点开任意一个，看它具体做什么、该在什么时候叫它。
emil-design-eng
这是整套 skills 的地基。它以动效为主，也覆盖界面层级、材质与留白。把它装上的意义不在于多一条命令，而在于你的智能体从此有一份可以反复引用的标准，而不是每次临场发挥。
什么时候用它
它具体做什么
可以这样提要求
›按 emil-design-eng 的规则，检查这个页面的动效与层级关系，逐条说明哪里不对。
animate
给你需要的那一处动效配齐所有配料：该用什么缓动、多长、动哪些属性、要不要错峰。它不会先给你一个默认值再让你自己调，而是在生成时就按规则把选择做完。
什么时候用它
它具体做什么
可以这样提要求
›用 animate 为这个筛选面板做展开与收起，说明每条曲线与时长的选择理由。
animate-expo
面向 React Native 与 Expo 的同标准实现：手势、底部弹层、页面切换、触觉反馈，以及最关键的让动效脱离 JS 线程。Web 上可用的直觉在这里大部分要改写。
什么时候用它
它具体做什么
可以这样提要求
›用 animate-expo 实现这个底部弹层的拖拽关闭，确保动画运行在 UI 线程。
review-animations
一次严格的复核。它会把你的动效拆成缓动、时长、属性、编排、降级几个维度，逐条指出哪里违反了规则，以及正确的写法是什么。适合在合并之前跑一遍。
什么时候用它
它具体做什么
可以这样提要求
›用 review-animations 审查这个 PR 里新增的三处动效，按严重程度排序。
improve-animations
面向整个代码库的审计。产出不是一份观感报告，而是一组有优先级、彼此独立、任何智能体都能直接领走执行的改进项。适合接手老项目或准备大规模翻新。
什么时候用它
它具体做什么
可以这样提要求
›用 improve-animations 审计 src/ 下所有动效，输出十条按优先级排列的改进项。
find-animation-opportunities
排查界面里真正能从动效中受益的位置。它的价值一半在建议做什么，另一半在拦住你：列表滚动、大段文本、高频重复的操作，加动效只会让人更累。
什么时候用它
它具体做什么
可以这样提要求
›用 find-animation-opportunities 看这个设置页，指出该加动效的三处和不该动的两处。
animation-vocabulary
多数糟糕的动效不是写坏的，是描述坏的。这个 skill 给你一套准确的词汇：回弹、跟随、迟滞、错峰、惯性。用这些词提需求，智能体第一次就能生成接近你想要的结果。
什么时候用它
它具体做什么
可以这样提要求
›帮我把「弹出来的时候要有点高级感」改写成 animation-vocabulary 里的准确描述。
apple-design
提炼自 Apple WWDC 设计演讲的界面与动效原则，并翻译成 Web 上能执行的写法。重点不是模仿 iOS 的外观，而是理解它为什么流畅：视觉连续性、层级清晰、响应即时。
什么时候用它
它具体做什么
可以这样提要求
›用 apple-design 的原则重做这个列表到详情的过渡，保证视觉连续性。
write-swift
面向 Swift 本身的工程 skill：值类型优先、Swift 6 并发、泛型设计、性能取舍，以及用 Swift Testing 写测试。让智能体输出符合当前语言习惯的代码，而不是 Objective-C 时代的直译。
什么时候用它
它具体做什么
可以这样提要求
›用 write-swift 重写这个网络层，遵循 Swift 6 并发规则并补上 Swift Testing 用例。
pick-ui-library
让智能体从作者实际使用并信赖的库里挑，而不是临场生成一个 toast 组件，或者装一个已经停止维护的包。选择依据是任务本身，不是热度。
什么时候用它
它具体做什么
可以这样提要求
›用 pick-ui-library 为这个表单挑一个日期选择方案，说明为什么不用手写。
prototype
针对你描述的 UI 片段同时构建几个方向不同的版本，并配一个切换器逐个浏览。判断界面好坏最有效的方式从来不是描述它，而是把几个版本摆在一起看。
什么时候用它
它具体做什么
可以这样提要求
›用 prototype 给这个空状态做三个方向，并加一个切换器逐个浏览。
mobile-native
顽固的 hover 态、点击高亮闪烁、100vh 的坑、聚焦就缩放的输入框、迟钝的点击、安全区域。这些细节单看都很小，合在一起就决定了你的应用像网页还是像 App。
什么时候用它
它具体做什么
可以这样提要求
›用 mobile-native 检查这个页面在手机上的表现，逐条列出违和的地方。
ask-sonner
作者开发的 toast 库 Sonner 的使用指南：配置、样式、常见配方，以及那些几乎每个人都会遇到的坑。一个提示组件做对了，整个应用的完成度会高出一截。
什么时候用它
它具体做什么
可以这样提要求
›用 ask-sonner 配一套表单提交提示，包含加载、成功与可重试的失败态。
单个 skill 只解决链条上的一段。差距出现在你把它们接起来的时候：先把需求说准，再做出来，最后按同一套规则检查一遍。选一个场景，看这条链是怎么走的。
这处动效该用哪条曲线，它能通过审查吗
animation-vocabulary
把「高级一点」翻译成回弹、迟滞、错峰这些具体描述
产出一份能被直接执行的需求描述
animate
按描述生成实现，同时把曲线、时长与属性一次选对
产出一处动效代码与每条参数的选择理由
review-animations
合并前按规则复核，把侥幸对的地方也确认一遍
产出问题清单与可直接替换的写法
只用其中一个
只用 animate，你会得到一处能跑的动效，但没法确认它符合你的原意，也没人检查它踩没踩坑。
串起来之后
描述、实现、复核三段闭合：做完就知道它对，而不是做完再看感觉。
提示词序列
1. 用 animation-vocabulary 把「弹出来要有点高级感」改写成准确描述。 2. 按上面的描述，用 animate 实现这个面板的展开与收起。 3. 用 review-animations 审查刚才的实现，按严重程度列出问题。
先改哪几处，改完怎么保证不回退
find-animation-opportunities
先排点：哪些地方值得动，哪些地方必须别碰
产出该做与不该做的清单，按感知强度排序
improve-animations
全库审计，把结论变成一条条可独立执行的改进项
产出带优先级的改进清单，可拆分并行
review-animations
每改完一批就复核一次，避免新改动引入新的不一致
产出逐条通过的复核记录
只用其中一个
只用 improve-animations，你会改掉所有错的地方，也会一起改掉本来就对的地方，还可能在安静的角落加出噪点。
串起来之后
先排点再动手，改动集中在用户真的会看到的地方，且不回退。
提示词序列
1. 用 find-animation-opportunities 看这个页面，指出该加的三处和不该动的两处。 2. 用 improve-animations 审计 src/ 下所有动效，输出十条按优先级排列的改进项。 3. 改完后用 review-animations 复核这一批改动。
违和感具体来自哪些细节，怎么系统性清掉
mobile-native
清掉 hover 残留、100vh 跳动、点击高亮、安全区域这些硬伤
产出逐条列出的违和点与修法
apple-design
补上平台级原则：视觉连续、层级清晰、响应即时
产出过渡与层级的重构方案
animate
按同一套规则打磨剩下的过渡，让手感统一
产出统一的动效参数与实现
只用其中一个
只用 mobile-native，你能修好所有技术性毛病，但页面仍然只是「不出错的网页」，不会变成「顺手的应用」。
串起来之后
先修硬伤，再补语汇，最后统一手感。三步之后差距是整体性的，不是补丁式的。
提示词序列
1. 用 mobile-native 检查这个页面在手机上的表现，逐条列出违和的地方。 2. 按 apple-design 的原则重做列表到详情的过渡。 3. 用 animate 统一剩下过渡的曲线与时长。
哪个方向值得继续，依据是什么
prototype
一次做出几个差异真实存在的版本，配切换器同屏比较
产出三到四个可切换的方向
apple-design
用平台原则评估并精修选定的版本
产出层级与过渡都站得住的定稿方向
pick-ui-library
确定实现所需的库，避免手写一个已有成熟方案的东西
产出选库结论与理由
只用其中一个
只用 prototype，你会得到几个版本，但仍然靠直觉选，而且选完常常发现实现要用的库选错了。
串起来之后
从比较、定稿到选库是一条链，拍板的时候同时知道它能不能落地。
提示词序列
1. 用 prototype 给这个空状态做三个方向，加一个切换器逐个浏览。 2. 按 apple-design 的原则精修选定的那个方向。 3. 用 pick-ui-library 确定实现要用哪些库，说明为什么不用手写。
还有哪些地方是「能跑但不对」的
review-animations
按规则逐条复核所有动效，先找出确定的问题
产出问题清单与替换写法
emil-design-eng
回到总纲，检查层级、材质、留白这些更基础的地方
产出界面层面的修正意见
improve-animations
把剩余问题排成可执行的清单，留到下一个迭代
产出带优先级的后续改进项
只用其中一个
只用 review-animations，你能保证动效没错，但没法判断界面本身是不是站得住。
串起来之后
动效、界面、后续计划三层各查一遍，发布时知道剩下了什么。
提示词序列
1. 用 review-animations 审查本次要发布的改动。 2. 按 emil-design-eng 的规则检查层级、阴影与留白。 3. 用 improve-animations 把剩下的小问题排成下一轮清单。
怎么让它跟手，又不掉帧
animate-expo
把动画放到 UI 线程，手势与动画共享同一个驱动源
产出跟手且可中断的实现
apple-design
对齐平台习惯：弹层、页面切换、返回手势
产出符合预期的交互语汇
review-animations
在真机条件下复核，参数与降级一并检查
产出上线前的复核结论
只用其中一个
只用 animate-expo，动画能跑在正确的线程上，但手势习惯与平台预期仍然可能对不上。
串起来之后
性能、语汇、审查三件事一起解决，真机上的手感才立得住。
提示词序列
1. 用 animate-expo 实现这个底部弹层的拖拽关闭，确保运行在 UI 线程。 2. 按 apple-design 的原则对齐页面切换与返回手势。 3. 用 review-animations 在真机条件下复核这批动效。
装完之后，在你的智能体里直接说「用 animate 做这个展开」即可。不需要额外配置，也不需要记住这份清单。
$npx skills@latest add emilkowalski/skills
装在哪里
写入当前项目的 skills 目录，随代码一起进版本库，团队共享同一套标准。
什么时候生效
下次对话即可调用。提到 skill 名字，或直接描述你要做的事。
想跟进更新
订阅作者的资讯简报，新 skill 与改动都会第一时间发出来。