Clear 是一个用于改写内容的技能，属于 tranz007/ux-skills 技能集。它的目标是让 UX、产品、研究、交接文档、工单或面向工程的内容读起来像一位有能力的人类从业者所写，而非机器生成。
用途
Clear 承担两项工作。其一，在被调用时，改写已有材料，使其更易理解、更便于据此行动。其二，Clear 的核心规则已嵌入每一个 UX Skill 之中，因此生成的 UX 工作从一开始就可读，而不需要事后清理。
核心规则
这些规则涵盖以下几个方面。
上下文（Context）：在要求用户重复信息之前，先查看已知内容。当产品目的或结果可能改变答案时，使用 .ux/INTENT.md，并且只加载任务所需的额外项目上下文。
用户（User）：把工作建立在受影响的人、其目标、任务、场景和已有证据之上。不要虚构用户需求、行为或人物画像。
证据（Evidence）：当区别重要时，保持已知、推断、假设、未知和冲突信息之间的区分。
系统（System）：优先采用既有产品语言、组件、模式和规则，而非发明新内容。
清晰（Clear）：先给出有用的要点，使用所需的最少结构，去除通用的 AI 填充内容。
信任（Trust）：绝不虚构证据、需求、理由、实现状态或合规情况。
结果（Outcome）：对于重要的多步骤工作，保持意图活跃；仅在需要连续性时使用一个小的 .ux/STATE.md；先处理影响最大的未解决缺口，再抛光；在宣布完成前，对照意图验证实际体验。
该技能指出，除非某条规则会实质影响回答，否则不要向用户复述这些规则；当用户和任务已经清晰，或缺失信息不会实质改变工作时，不要引入研究问题、人物画像或探索性工作。
使用方式
改写前，先推断或确定：谁需要阅读；他们需要理解什么；他们需要决定或做什么；哪些细节是必要的；哪些不确定性或证据状态必须在改写后保留。如存在最小相关项目上下文，则使用其中的术语和沟通约束。
需要修正的生成式文档习惯包括：通用开头和结尾；过多的标题、项目符号或嵌套结构；强行凑三组；将加粗用作装饰；重复性重述；企业套话和夸大主张；本可用具体名词或行为表述却使用模糊抽象；套话式赞美、安慰或聊天机器人式客套；隐藏行为主体的被动结构；千篇一律的句子节奏；不必要的含糊或过于确定；承载多个决策的密集句子；对读者无帮助的 UX 或技术术语；有经验读者不需要的解释；仅重复已说内容的总结。同时，不要仅仅为了避开 AI 腔调而加入虚假的随意、俚语、玩笑或个性。
需要保留的内容
绝不为了提升可读性而改变事实、证据强度、需求、范围、未决决策、用户引述、技术行为、无障碍期望或法律政策含义。如果来源不清楚或自相矛盾，应保留该不确定性，而不是将其抹平。
按读者调整
面向设计师时，强调问题、证据、备选方案、不确定性和设计后果。面向工程师时，强调行为、状态、组件、约束、依赖、验收标准以及需要评审的内容。面向利益相关者或高管时，强调决策、影响、证据、风险以及下一步所需。面向研究参与者时，去除内部语言，降低认知负担，避免引导性措辞。
信息设计
不要只是改写句子，而要重新组织信息，让有用的要点先出现；删除读者不需要的材料；将相关想法归组；仅在能减少费力时使用结构。完成前可自问：有没有内容可以在不损失含义的情况下去掉？最重要的要点是否容易找到？我是否不小心把不确定性变成了确定性？这听起来是否像一个从业者在与另一个人沟通，而不是一份生成的文档？如果不然，再简化一次。
对比示例
研究摘要。差：研究清楚地表明用户强烈偏好更直观、更流畅的预订体验，凸显出提升整体满意度的重大机会。好：五位参与者中有三位在结账前错过了票价变动警告。这表明该警告容易被忽视；但这并不能证明整个预订流程需要重新设计。原因：好的版本具体，保留了证据强度，避免把小发现变成宽泛断言。
工程交接。差：此增强创造了无缝的恢复体验，改善了所有错误状态下的可用性和无障碍。好：如果验证失败，保留已输入的验证码，显示行内错误，并把焦点移到错误摘要。验证码过期状态仍未解决，工程不应自行推断。原因：好的版本告诉读者改了什么、必须发生什么、还有什么未知，而没有宣传性语言。
适用场景
示例调用包括：让这份交接文档对工程更易读；这份研究摘要听起来像 AI，改一下；在不改变证据的前提下让它适合给高管看；清理一下但不要变成企业套话。
限制
资料未提供该技能的定价、平台支持、安装命令或代码细节。其依赖的 .ux/INTENT.md 与 .ux/STATE.md 文件的具体格式与内容，资料亦未提供。