frontend-motion-prompt-writer

Packaged Knowledge Snapshot

This packaged copy includes local note snapshots for portability. When the original Obsidian absolute path is unavailable, use the packaged snapshot instead:

• /Users/kunkun/note/01-AI工程/AI设计与前端/02-执行方法/AI 前端动效盲区与采访补偿.md -> references/packaged-knowledge/AI 前端动效盲区与采访补偿.md
• /Users/kunkun/note/01-AI工程/AI设计与前端/02-执行方法/动效文档两层：MOTION-SPEC vs 实现 prompt 集.md -> references/packaged-knowledge/动效文档两层：MOTION-SPEC vs 实现 prompt 集.md
• /Users/kunkun/note/01-AI工程/AI设计与前端/02-执行方法/视觉锚定三件套：代价结构与资产生成双路径.md -> references/packaged-knowledge/视觉锚定三件套：代价结构与资产生成双路径.md

Frontend Motion Prompt Writer

这个 skill 在做什么

把动效从宏观清单（人读的量化语法）翻译为微观代码级规格（Agent 直接读、写 framer-motion 代码的完整 prompt）。一个核心动效组件一份 prompt，参考 LoadingScreen 范式：Theme tokens / 字体引用 / 组件签名 / 逐元素规格 / 父组件行为 / 时序总表六个要素齐备。

动效文档两层的分工

本 skill 负责微观层，不碰宏观层：

层	给谁读	产出 skill
宏观层（MOTION-SPEC.md / design.md §10）	人 + Agent 并读	frontend-design-writer（§10）
微观层（motion-prompts/{Component}.md）	Agent 直接读 → 写代码	本 skill

两层互补：宏观层定义"整站动效清单 + 量化语法 + 双向性约定"；微观层是单个组件的完整代码级实现规格。单独任一层都不够——只有宏观会生成风格各异的实现，只有微观会在没定组件架构时就锁死细节。

详见 [[动效文档两层：MOTION-SPEC vs 实现 prompt 集]]。

在阶段化流程里的位置

本 skill 触达于阶段 4C 尾部 和 阶段 6 代码实现：

阶段4 视觉锚定三件套
  ├─ A. Moodboard
  ├─ B. 完整网页示意图
  └─ C. 动效帧序列（frontend-visual-reference 产出帧序列图）
         ↓
       ★ 本 skill：把帧序列 + MOTION-SPEC + 组件签名翻译成微观 prompt
         ↓
阶段6 代码实现 ── Agent 读 motion-prompts/{Component}.md 写 framer-motion 代码

按需触发，不是一次性写完——阶段 4C 结束时可能只写最核心的 1-2 个；阶段 6 代码实现每触达一个新核心动效组件，现场生成一份微观 prompt。

何时进入本 skill

要进：

• 阶段 4C 帧序列完成，需要把最核心动效（如 LoadingScreen、Hero 入场）翻译为代码规格
• 阶段 6 代码实现，Agent 触达某个核心动效组件，需要完整实现 prompt 引导
• 用户说"写 LoadingScreen 的动效 prompt""把 Hero 入场翻译成代码规格""我要一份能直接喂 framer-motion 的 prompt"

不要进：

• 写宏观 MOTION-SPEC.md / design.md §10 → frontend-design-writer
• 生成动效帧序列图（视觉锚点） → frontend-visual-reference（阶段 4C）
• 动效采访（节奏/触发/双向性/层级/反例 5 类） → frontend-design-research（阶段 2 的六维之动）
• 直接写 framer-motion 代码 → 开发实现剧本
• 简单 hover / 按钮 scale / 单 fade 等次要动效 → 不写微观 prompt，只在 §10 登记