preparing-design-handoff

准备设计交接

此技能是设计阶段的最终关卡。工程团队依靠一套一致的信号来判断设计是否已准备好交付。交接时缺少任何一个信号，都会引发后续问题，并拖慢 Epic 进入开发的进度。

交接包含两项内容，而非一项

以下两项都完成后，交接才算完成：

1. Figma 文件处于 Ready-for-Dev 状态。 最终设计集中在同一页面上，各分区的命名与将采用这些设计的工程故事一致。Figma 中的分区标记为“Ready for Dev”。在画板上标注用户可见文案（Toast、错误消息、表单验证文案、邮件正文文案）。提供带注释的原型。
2. Jira 状态已同步。 Figma 文件已关联到 Epic 的“Design”字段，Figma 中的分区已标记为 Ready for Dev，EM 将 Epic 转换为 Ready for Dev。完整流程见 navigating-design-jira-process。

如果缺少任何一项，交接就尚未完成。

准备清单（宣布交接前）

• 产品计划或 PRD 页面已创建且内容为最新。
• Jira 中已创建工程 Epic，且设计师已分配或曾被分配到该 Epic。
• 设计已完成 30%、60% 和 90% 阶段的评审，并已处理 90% 阶段评审的反馈。
• 适用时已进行真实用户测试（这正是 90% 阶段的目的）。
• Figma 文件的最终设计页面已整理妥当——Ready-for-Dev 区域中没有草稿页面或未使用的画板。
• 所有用户可见文案都已在 Figma 中标注，并与适用的画板对应。

如果有任何一项未完成，请在宣布交接就绪前指出——不要等到交接时才发现 90% 阶段的评审从未进行。

Figma 就绪检查

将分区标记为 Ready for Dev 前，请确认：

• 分区与故事对应。 每个命名分区都对应一个工程故事。避免分区跨越多个故事，或一个故事跨越多个分区。
• Token 关联到库。 设计系统变量存在时，不要使用原始十六进制值。结合使用 using-figma 和 get_variable_defs 进行验证。
• 文案已标注。 每条用户可见文案——按钮标签、错误消息、Toast、空状态、辅助文本——都已放在 Figma 画板或注释中。
• 已覆盖边缘情况。 相关画板中包含空状态、错误状态、部分成功状态、离线状态和高级功能限制状态（或明确标注为不在范围内）。

与其他技能配合使用

• using-figma。 使用 get_metadata 确认 Ready-for-Dev 分区已创建且名称符合预期；使用 get_variable_defs 确认 Token 关联到库，而不是原始值；如果设计中的某个组件看起来与已有组件非常相似，则使用 search_design_system。
• navigating-design-jira-process。 与交接配套的 Jira 操作——将 Figma 文件关联到 Epic 的“Design”字段、在 Figma 中标记为 Ready for Dev，以及由 EM 转换 Epic——都在此处说明。
• content-style-guide。 宣布交接前，按照风格指南逐一检查每条已标注的文案。Toast、错误消息和表单验证文案最容易在工程团队进行本地化之前发现内容风格问题。

常见遗漏检查项

• Figma 文件中没有 Ready-for-Dev 标记。 工程团队无法确定哪些内容是最终版本。这是最常被漏掉的一步。
• 分区与故事不对应。 每个故事都应对应一个 Figma 分区，且该分区只包含该故事的内容。不匹配会导致评审时出现歧义。
• 缺少文案标注。 工程团队一开始处理 Epic 就会询问文案。宣布交接前，请在 Figma 中将文案与对应画板一并标注——不要把编写文案的工作推给工程团队。
• 缺少边缘状态。 空状态、错误状态、部分成功状态、离线状态、高级功能限制状态。如果这些不在范围内，请在画板或开发支持评论中明确说明。

输出格式

在被要求协助准备交接时：

1. 准备清单 — 已就绪的内容和缺失的内容。
2. Figma 就绪情况检查 — 检查章节与故事的对应关系、令牌绑定、字符串注释和边缘状态。
3. Jira 操作 — 需要执行的具体状态转换和要应用的 Figma 链接（链接到 Epic 的 "Design" 字段，将章节标记为 Ready for Dev，由 EM 转换 Epic 状态）。请以 navigating-design-jira-process 中的规范操作流程为准。

结尾务必明确说明是否通过：这次交接是否已真正准备就绪？