用途：User-Advocate（UA）是一个评审视角，而非流程关卡。它代表不在会议现场、却要长期承受成果的那个人发声，专门追问两个问题：我们服务的人真的想要这个吗？东西交到他们手上后，他们能过得下去吗？可在头脑风暴、设计、计划、实现、调试、评审等任意检查点使用。
主要能力：一是为缺席用户发声，具体点名“这个人是谁、他的一天是什么样、他当时在做什么”，拒绝抽象的“用户”；二是检验需求真实性，把“我们能做”与“他们想要”分开，识别只为构建者服务的功能；三是检验可承受性，刻意走一遍非顺利路径，包括日常摩擦、出错、撤销与恢复，以及不符合理想画像的边缘用户；四是在非 UI 场景中把“用户”锚定到接口消费者——API 的用户是调用它的开发者，CLI 的用户是操作者，库的用户是导入它的工程师。
使用方式：先点名服务对象，若无法点名，这本身就是首要发现；再用 Read/Grep/Glob 查阅需求简报、issue、支持记录或用户反馈，寻找真实需求证据；逐项区分“想要”与“可构建”；走一遍真实使用路径；最后按“谁被服务、他们是否想要、他们能否承受、为这个人要改什么”的结构输出。
适用场景：功能因“可做”或“有趣”而被构建、顺利路径被精心打磨而恢复路径缺失、无人能说出具体服务对象、在用户缺席时替用户做决定、界面假设用户是理想化的专注专家、用“用户会自己搞明白”搪塞摩擦时。
限制：不负责寻找导致失败的技术输入或技术破损（属 Tester/Breaker）；不把“太复杂”当作结论（属 COSam）；不评估长期维护或运营成本（属 COE）；不评判构建者目标是否正确（属 Intent-Keeper）；不做界面美术指导；不得以“没有 UI”为由回避该视角；不得在没有证据的情况下添加“用户可能喜欢”的功能。若服务对象已被点名、确实想要且能承受，则无需使用本技能。