Handoff 是一个 UX 设计交付技能，核心目标是“传递设计意图，而不仅仅是外观”。它帮助设计者把已批准的设计方案整理成工程团队能够直接实现和测试的交接材料。
用途 该技能用于将 UX 工作准备给工程团队，保留用户意图、行为、状态、设计系统用法、无障碍要求、依赖、验收标准等信息。它适用于“把这份已批准的流程整理成实现交接”“把行为写清楚，让工程和 QA 能测试”“拆成可构建的工单，同时不丢失 UX 意图”等场景。
主要能力
- 收集事实来源：检查已批准设计、相关流程与状态决策、设计系统组件、内容、无障碍要求、约束、决策记录以及团队现有工程工作流。只加载保留预期体验所需的项目上下文。
- 就绪检查：在打包工作前，查找会导致工程猜测的问题，包括缺失状态或恢复、模糊过渡、未支持的新组件或模式、未解决的内容或术语、未定义的无障碍行为、会实质改变体验的数据或服务条件、仍未决的重要决策。
- 解释行为：优先说明工程真正需要的内容，包括用户目标与结果、进入条件与主要行为、有意义的分支与恢复、组件与模式用法、状态与数据条件、相关时的响应式行为、内容规则与术语、已确立的无障碍行为（如焦点、播报、语义、键盘交互）、依赖与约束、未决问题。
- 适配团队工作流：如果团队需要 Jira、GitHub Issues、Linear、Azure DevOps 或其他工单格式，可将交接转化为可构建的工作，同时不拆分成无意义的 UI 碎片。如果用户只需要交接，则不应仅因为可以就创建工单形式的输出。
- 输出最小工程包：创建最小的工程包，使预期体验清晰且可测试。指向权威的设计系统、决策、研究、意图或设计来源，而不是重复它们。
使用方式 该技能强调在提问前先检查已知信息，使用 .ux/INTENT.md 在产品目的或结果可能改变答案时提供上下文，仅在需要连续性时使用小型 .ux/STATE.md。它要求区分已知、推断、假设、未知和冲突信息。在描述行为时，可使用如下格式提高精确度：当 <条件> → 系统 <行为> → 用户 <看到/听到/可以做什么> → 相关状态 <保持/重置/改变> → 恢复 <行为>。
适用场景 适用于 UX 设计向工程交付的阶段，尤其是需要保留行为、状态、无障碍意图和未决决策的复杂流程。也适用于需要将设计交接转化为可测试工单的团队。
限制 该技能明确要求不编造证据、需求、理由、实现状态或合规性。不将状态不明确的提议行为描述为已批准。不因文档不影响实现而阻塞交接。不向用户背诵规则，除非某条规则实质影响答案。不在用户和任务已清晰或缺失信息不会实质改变工作时引入研究问题、人物角色或发现工作。
示例对比 差：“根据 Figma 实现更新后的验证屏幕。包括加载和错误状态，并确保体验可访问。” 好：“当验证失败时，停留在当前步骤，保留已输入的代码，显示内联错误，并将焦点移到错误摘要。复用现有的 Alert 和验证输入模式。过期代码的恢复路径仍未解决；工程不应自行发明该行为。” 原因：好的交接传递了行为、系统用法、无障碍意图和未决决策，而不是给工程一张图加模糊指令。