用途：让某个具名交互的行为对设计师和工程师足够明确，使双方能构建并验证同一体验。契约描述的是可观察的承诺，不要求特定状态机库或架构。
主要能力： 一是识别未解决的承诺。借助已有简报、界面、组件 API 和实现，确定使用者、任务、起始状态与支持的输入；除非任务要求变更，否则保留既有行为，并区分需求、观察到的行为与提议的变更。只覆盖有实质影响的不确定性，而非每个可能事件。若缺失的产品决策会实质改变契约，应先询问；否则给出合理假设继续。要求规格不等同于要求实现。 二是描述可观察契约，可用紧凑表格、带注释流程或团队既有格式，涵盖：进入与触发（前置条件、可用输入、触发来源）；状态与反馈（立即变化、待处理项、完成确认）；归属与持久化（权威值所在、何时提交、离开返回后保留什么）；中断（取消、Escape、导航、另一输入或二次提交的含义）；失败与恢复（保留什么、如何解释失败、如何继续）；焦点与可访问性（控件含义、支持的键盘或辅助输入、焦点移动、相关时的减少动态效果替代）。 需区分取消编辑、取消请求与撤销已提交变更；若取消无法回退远程效果，不应承诺可回退；乐观反馈需说明失败与对账；当差异对任务重要时，区分本地接受与服务器确认。
使用方式：检查可能的交叠操作（重复提交、待保存期间编辑、离开返回、旧响应晚于新响应到达），仅在受支持用法可触达时纳入序列，并说明哪种结果可更新 UI，而不规定不必要的实现机制。将契约带入工作：设计侧表达所需状态与转换，代码侧映射到既有状态归属、控件与服务边界，不因追求整洁而替换架构。用可观察结果验证代表性序列；对关键状态或持久化变化使用行为测试，仅靠目视无法确立这些承诺，模拟服务只证明其模拟的行为。报告缺陷时说明受影响的消费者与任务、前置条件与复现步骤、预期与实际行为及影响；未执行的关切应作为假设。
限制：本技能只定义行为，不把局部交互扩展为整个产品的加固；资料中未提供具体收费、平台与安装命令信息。