Seenry Review 是一个用于审查 Web 界面、UI 差异或单个组件的技能，主张“评判渲染出来的结果，而不是代码的意图”。每条发现都要求可见、具体、按严重度排序，并给出最小修复方案。审查以 Seenry 系统的规则为标准，包括网格与间距、各组件字号限制、同心圆角、单一强调色、一致的页面外壳以及反模板化清单。
用途与原则
该技能用于设计批评、UI 审查和无障碍检查等场景。如果界面由使用者自己构建，应说明并视为自审，最好换一个全新的智能体上下文。报告只写能展示的证据：测量值、截图、失败的检查项或带数字的规则。若项目有意选择并一致地应用某种密度、圆角或语气，则不应仅因个人偏好不同而列为问题；但下列高风险触发项要重点检查：交互控件缺少可访问名称、可见焦点或键盘路径；内容或控件在 320px、200% 缩放或被键盘遮挡时被裁切、重叠或无法访问；文本或控件在实际渲染表面上的对比度低于要求；仅靠颜色或仅靠动效传递状态或含义；动效忽略 prefers-reduced-motion，或在每天 100 次以上或键盘驱动的操作上使用动画；破坏性操作没有确认、撤销或区分处理；截断内容无法查看完整值、错误无法恢复；语义颜色与含义不符；占位素材被当作最终内容发布。修复方案优先选择最省事的做法：删除、使用平台原生能力、复用项目 token 或组件、修正数值，最后才考虑新增内容。同一根因合并为一行并列出所有位置，最多报告 15 条，触发项优先；如因上限被截断需说明数量。
使用模式
用户要求“审查/批评/审计这个页面、屏幕或网站”时进入屏幕审查；“审查这个分支/PR/提交/我的改动”时进入变更审查：对基线运行 git diff，列出受影响的 UI 表面，渲染改动前后，仅审查这些表面；“压力测试/弄坏这个组件”时进入压力测试；“这个可访问吗/WCAG”时进入仅含无障碍检查清单的屏幕审查；“审查/改进动画”“哪里该加动画”时进入动效审查；“这是怎么构建的/解释这个交互”时进入解释模式。
屏幕审查
在 1440 和 390 宽度下打开页面（检查溢出时加 320），分别截图，并用指针和键盘执行主要操作。先审查完整流程再看动效：说明组件用途、进入方式、每个有意义的操作及其可见结果，检查可发现性、返回/取消/关闭行为、焦点返回、空/错误/禁用状态、重复或中断操作以及手机适配。只有给出理由时才可标记某状态不适用，未测试的状态视为未验证。关闭方式应适配流程：确认对话框可用取消和 Escape 配合原生模态行为，导航流程可用返回，不要求每个对话框都有额外的关闭按钮。源点返回控件是直接展开卡片或切换流程的空间准则，而非通用对话框要求。测量时运行 node ../seenry/scripts/audit_page.mjs <url or file> --widths 1440,390,320 --shots <dir> 做页面审计，合并系统审计与光学审计，记录字号、字重、字体族、圆角、阴影、脱离网格的值、嵌套圆角违规、超限组件、水平溢出，以及每个组件的对齐锚点、近似边缘和光学内边距；可切换网格叠加检查共享边缘。审查顺序为：任务与层级（5 秒内是否清楚这是什么、给谁用、下一步做什么，主操作是否最突出）、素材与锚点（真实图片/图标/数据还是占位，元素是否对齐到其他元素的边缘或中线）、布局（共享内容边缘、区块节奏、分组、阅读顺序、手机重排）、字体（字体族数量、每组件和页面的字号字重、展示字重与字距、行宽、换行）、颜色与表面（强调色面积与角色、对比度、层次选择、圆角族与同心性）、组件与状态（悬停、焦点、激活、禁用、加载、空、错误、溢出）、内容（文案是否具体、数据是否真实、声明是否有佐证）、无障碍（键盘路径、焦点可见性、名称、对比度、目标尺寸、缩放、减少动效）。必要时可与参考对比，借助 Seenry MCP 从 2–3 个同类强站拉取同类型页面并指出具体差异关系。
报告格式
一张按严重度排序的表，每行一个根因，列出所有位置，列为：严重度、位置、现状、改为、原因。严重度定义：高（在支持的尺寸下阻碍任务或隐藏内容/操作、对比度或键盘失败、或一眼就像生成的）、中（损害层级、一致性或清晰度）、低（打磨）。表后给出两种宽度下的系统审计统计、已验证与未验证的内容（动效、屏幕阅读器、设备），以及一行结论：发布、修复后发布（仅中）或阻塞（任何高）。不要未经要求重写页面，可提出代为应用修复。
变更审查
问题应是“这次改动是否让界面变差”，而非“代码库有什么问题”。确定范围：有指定 PR、分支或提交范围则使用之；否则取默认分支合并基之后的提交加未提交改动；再否则仅未提交改动；都没有则停下询问。把文件展开为界面表面：改动的 token、共享组件或样式表会影响所有使用它的屏幕，需列出这些屏幕，并在两种宽度下渲染改动前后（可用 worktree 或 git stash）并分别运行页面审计。阅读被删除的行：删除的焦点样式、aria-* 属性、alt 文本、减少动效块、min-width: 0、标签和错误处理即使新增代码看起来正常也属回归。按声明的意图（PR 描述、提交信息）衡量改动，半成品上线也是发现。每条发现分类为“引入”“回归”“既有”（既有最多报告三条，单独成节，不计入结论）。标出绕过 token 的硬编码值及其文件行号。正确性、安全和性能留给常规代码审查。
动效审查
清点范围内的所有过渡、动画和手势，逐项记录频率层级、目的、工具、属性、时长、缓动或弹簧、中断处理、减少动效与悬停门控，并对照 seenry-motion 的构建序列和 Never ship 表评估；在正常速度和 DevTools 动画面板 10% 速度下观看。同时列出遗漏的机会（需要连续性的突兀跳变、无反馈的按压）和被否决的候选（应保持即时响应及其原因），按表格格式报告。
压力测试
在临时页面单独渲染组件并同时展示所有现实变体：内容方面包括空、1 个字符、典型、2 倍长、5 倍长、不可断字符串（URL、邮箱）、emoji 与中日韩文字、RTL（若支持）、缺失图片、0/1/99+/1,000,000 计数、负数；状态包括默认、悬停、焦点可见、激活、禁用、加载、错误、成功、选中、展开；容器宽度包括 240、320、390、768、1200、200% 缩放、增大文字间距；输入包括鼠标、仅键盘、触摸模拟、快速重复点击、过渡中反向。对变体网格截图，运行系统审计和文本碰撞检查，以表格格式报告失败项。完成后删除临时页面，除非被要求保留。
解释模式
先描述观察到的现象，再推测可能的构建方式，最后说明为何适合该任务，并区分观察与推断。对线上站点可读取 DOM 和计算样式；对动效应录制或逐帧查看（截图不能证明时序）。借助 Seenry MCP 的 get_page_motion 和 get_design 可获得录制和测量样式。最后说明如何在不复制品牌素材的前提下把机制适配到用户产品。