ui-brief 是一个写设计简报的技能，用来在真正开始构建或重建界面之前，生成一份“有观点、以设计为先”的 UI 简报；这份简报可以粘贴进新的 Claude Code 会话，直接交给实现者执行。它不写代码，交付物是一份独立的 Markdown 文件。
用途与定位 它要解决的核心问题是：由大模型驱动的 UI 工作，很容易收敛到同一种通用的卡片网格默认样式。ui-brief 通过把产品的真实核心优势、具体参照对象和明确的负面参照写进简报，让实现阶段不容易回到那种默认状态。与同类技能的分工是：需要把实现工作交给 Claude Code 时用它；想要高保真草图或 A/B/C 方向时用 claude-design-brief；想直接建出界面时用 frontend-design 或 frontend-agent；构建完成后再用 ux-review 在真实浏览器里评审。典型链路是：先写简报，再由编排器与前端代理构建，最后验证。
两种模式 新建模式：面向尚无界面的项目，比如新产品、全新应用、此前没有界面的功能。简报在开头确立愿景与目标风格参照，只预判失败模式，没有需要诊断的现状。常见触发语包括“给我做一个 X 的界面”“我想要它看起来像某个参照”“为新仪表盘做设计”“为已有的 API 做前端”。 重建模式：面向已有但价值被埋没、观感同质化的界面。简报先诊断现状问题（配截图），再给出替换方案，目标是新界面与旧截图对比时能看出明显不同，而不是只换了一层颜色。常见触发语包括“现在的界面很差”“重新设计这个仪表盘”“别让它看起来像每个 shadcn 管理后台”“设计太通用”“重建前端”。 两种模式的大部分结构相同，区别在于开篇部分（愿景对比问题诊断）、调研重点（技术栈与参照对比技术栈、截图、路由与闲置库）以及完成标准中的截图对比项。
简报包含的内容 典型简报约 200 到 350 行 Markdown，包含这些部分：开篇（愿景或问题诊断）、论点（用一段话提炼产品真正的核心优势，所有设计决策都对照它评估）、设计语言（给出具体的正面与负面参照应用以及命名风格，避免只用“干净”“现代”这类形容词）、硬性规则（8 到 12 条带具体锚点数字的有观点规则，并说明它们只是判断起点）、逐页简报、组件原语（8 到 12 个可复用组件及其隐含 API）、动效、声音与通知、无障碍与响应式基线（axe AA、指定视口、移动优先、断点令牌、不在布局容器上写死宽度、不用内联样式做布局）、实施纪律（说明构建阶段应该组合哪些技能）、完成标准，以及给执行者的注意事项。
使用方式 流程依次是：先做 2 到 5 分钟调研，读 README、CLAUDE.md、package.json，确认技术栈和已装但少用的库，列出路由与已有组件，查找仓库中的截图或设计稿；然后完成诊断（重建模式）或制定愿景（新建模式），提炼核心优势；再挑选 2 到 3 个正面参照和 2 到 3 个负面参照；随后依据简报模板结构撰写，但每节都要填入项目专属观点，默认写到仓库根目录的 UI-CHALLENGE.md，已存在则写 UI-CHALLENGE-v2.md；最后逐项自检。如果无法从项目文件确定产品核心优势，应向用户提一个针对性的问题，而不是猜测。
完成标准与限制 完成标准必须包含“在浏览器中加载且控制台零报错”，以及截图对比项（重建对比旧截图，新建对比目标参照或设计稿）。当产品的核心优势依赖实时数据、真实服务或集成时，还需要一条“核心优势是真实的”项，跑一次真实路径，而不是用模拟数据。如果简报刻意只做界面、不接后端，必须在开头声明这是 SHELL 规格说明。需要注意：这是一份简报而不是契约，实现者应当带入自己的判断，锚点数字只是起点。