用途：把功能简介或 PRD 转成结构化设计简报，让设计师在动手前先掌握用户背景与约束，而不是走错方向后再补救。
必填输入（缺失时需向用户询问）：功能简介或 PRD（草稿笔记也可）、设计师姓名或团队、已知技术约束、设计截止时间。
流程：读取功能简介；把功能语言改写为用户目标与结果；识别技术、品牌、无障碍等约束；列出设计需处理的边界情况；定义可评估的成功标准；撰写“不在范围内”防止范围蔓延；最后校验每条边界情况足够具体、每条排除项足够明确。
简报结构：Design Brief 标题、用户目标（用用户的话，格式“When I…, I want to… so that I can…”）、背景与情绪状态、设计成功标准、约束（技术/品牌/无障碍/法律合规）、需设计的边界情况、明确不在范围内、参考资料（用户研究、组件库、竞品链接）。
对比度辅助：对比度不能靠肉眼判断，AA 线为 4.5:1，如 #777777 在白底为 4.478（不通过），#767676 为 4.54（通过）。可用以下命令计算： npx --yes notugly fix "#8ab4f8" "#ffffff" npx --yes notugly onepager <url> --out review.html npx --yes notugly vision 第一条返回比值、APCA 亮度对比及同色相最接近的通过色，应把实测数值写入交接表中的每个颜色旁。
质量检查：用户目标用用户语言；至少一个边界情况覆盖错误或失败状态；成功标准可测量或可观察；排除项至少包含一项看似在范围内但实际不是的内容；技术约束具体到工程可确认。
反模式：不用功能语言写用户目标；不跳过排除范围；不写“处理错误”这类通用边界情况；未确认工程约束准确前不交接；不省略用户情绪背景。
限制：技能本身未提供具体价格、平台或效果数据。