用途：把界面作为一个整体系统评审。它本身只负责编排，不重复或覆盖各领域规则：无障碍归 better-accessibility，结构归 better-layout，文案归 better-writing，字体归 better-typography，颜色归 better-colors，视觉打磨与动效归 better-ui。评审按上述顺序进行，避免基础性缺陷被表面修饰掩盖；构建时反向使用同一套归属，先确定改动涉及哪些领域再写代码。
模式：quick 只查主用户路径与高流量状态，仅报 HIGH 与 MEDIUM，上限 5 条；core 在六个领域探测后最多评判两个领域，其余标为“仅探测”；full 覆盖请求范围内全部状态并对每个产生候选的领域派发评判通道，上限 15 条；build 实施改动后针对 diff 自评，上限 15 条且限定于 diff。core 最多评判哪两个领域，按阻断潜力、高置信候选数量、评审顺序依次决定。
流程：先做侦察，识别框架、样式系统、组件库、设计令牌、支持视口与可用预览或测试命令，供各通道复用；再以已安装代码为准做清单、探测、评判与合并。评判需给出 path/to/file:line 与当前实现，按用户影响排序，同一根因合并为一条，并记录被拒绝的候选与验证结果。
限制：若某个归属技能不可用，该领域标记“未评审”并继续，不得凭记忆重建规则或声称整体覆盖。任一领域处于降级、未评审或仅探测状态时，结论为“无定论”。默认评审为只读，除非用户还要求实施或使用 build 模式。派发通道成本较高（资料称单个探测通道在 484 行组件上约 150k tokens、14 分钟），具体命令、安装方式与收费信息暂未提供。