brand-motion-guidelines
This skill should be used when the user asks to "write motion guidelines", "create a brand motion system", "define easing and timing tokens", "document our animation principles", "build a motion language like Slack/IBM/Klarna", "set up entrance/exit/transition rules", or "add a reduced-motion / accessibility section". It outputs a fill-in-ready brand motion guidelines document.
1How It Works & Mechanism
Outputs a fill-in-ready brand motion guidelines document, structured and written strictly in seven fixed sequential sections (Principles → Tokens → Choreography → Logo Rules → States & Feedback → Accessibility → Do / Don't).
A complete motion guidelines doc has seven parts. Author them in order:
Assesses project scope before starting: a single site/campaign uses a lightweight version, a full product uses the complete seven-section structure, and cross-product + marketing + broadcast additions include Motion Personality presets.
How many surfaces/teams will use this?
Token naming must be semantic (based on purpose rather than literal values), allowing values to evolve without causing global renames.
| Token values renamed constantly | Names are literal (`duration-250`) | Name by purpose (`duration-base`) so values can change |
Asymmetric entrance/exit timings and stagger caps are codified as default rules: exits are faster than entrances, and staggers are set between 30–50ms.
Default rule: exits are shorter than entrances; staggers use small offsets (30-50ms) so groups feel alive without dragging.
Accessibility is an essential, mandatory section rather than an appendix: covering reduced-motion, photosensitivity thresholds, focus visibility, and a strict ban on conveying state via color or motion alone.
- **Photosensitivity**: no more than 3 flashes per second; avoid full-screen high-contrast strobing.
"Vibe-based guidelines" are explicitly treated as anti-patterns: adjectives cannot be engineered and inevitably lead to product inconsistencies.
Why it fails: no named tokens, no values, no entrance/exit rule, nothing implementable — "smooth" and "snappy" contradict and every engineer interprets them differently
Positioned strictly as a system-of-record: foundational upstream theories (three pillars, three layers of motion, 1/3 rule) and personality presets are provided by companion skills; this document references them rather than duplicating them.
This doc is the *system-of-record* for a brand's motion; two sibling skills supply the upstream theory and the per-project feel — reference and apply them, don't duplicate their tables:
The fill-in-ready template is embedded directly within SKILL.md (including versioning, ownership, eight subdivisions, and ✅/❌ placeholders).
8. DO / DON'T
2Core Capabilities
3External Dependencies
| Kind | Dependency / Endpoint |
|---|---|
| package | 兄弟 skill:animation-principles(三支柱 / 三层运动 / 1-3 规则)与 motion-art-direction(Motion Personality 预设)——均属 iart-ai/motion-design-skills 仓库 |
| package | spring(stiffness, damping) 令牌(实现侧能力,文档只给命名位) |
4Recommended Governance & Evidence
- SKILL.md: Pure prompt instructions and structured rule text; contains no script execution or external side effects
5Second-Pass Verification
- [ok] 是否存在任何脚本或可执行片段 — 全目录只有 Markdown;代码块仅含 cubic-bezier 值、spring(stiffness, damping) 这类命名占位与模板文本,无 shell/JS 可执行语句。
- [discrepancy] 跨仓引用的两个兄弟 skill 是否能解析 — SKILL.md 的 Related frameworks 要求引用 animation-principles 与 motion-art-direction,但这两个 skill 属 iart-ai/motion-design-skills(另一仓库、另一 pack)。只安装 freelance-motion-skills 时引用悬空(文档既未标注需另装,也未内联最小词汇表),实际使用需同时装 motion pack。
- [unlocatable] 无障碍与光敏阈值等条款是否有出处 — 「≤3 次闪光/秒」「聚焦指示不可被动画隐藏」等属通用可访问性实践(对应 WCAG 类准则),但 pin 仓库内未给标准编号或链接;作为文档声明记录,合规场景应自行对照当期 WCAG。
- [ok] 「输出是文档不是代码」是否与全文一致 — SKILL.md 在 When to use、常见错误表与交付 spec 三处均强调产出为 structured document;令牌表里的 cubic-bezier 是内容而非实现代码,与声明一致。
6Verdict & Scenarios
9ea95c6713578b29…