首页龙虾技能列表 › UX Baseline Check — UX质量标准检查

UX Baseline Check — UX质量标准检查

v1.0.0

核心技能包 — 视觉和前端工作的UX质量标准检查工具。强制对任何屏幕、流程、表单或仪表盘执行UX质量标准,确保发布时不遗漏任何状态。随设计审查自动激活,适用于所有前端工作。

0· 105·0 当前·0 累计
by @aa-on-ai (ai-ron)·MIT-0
下载技能包
License
MIT-0
最后更新
2026/3/21
安全扫描
VirusTotal
无害
查看报告
OpenClaw
安全
high confidence
一个仅包含指令的UX检查清单,与其声明的用途内部一致,不请求凭据、安装或系统访问;轻微的元数据/措辞不匹配不表示恶意行为。
评估建议
这是一个低风险的、仅指令的UX检查清单,与其声明的用途匹配。在安装前:(1) 注意README措辞(“核心/始终激活”)和注册表标志(always: false)之间的不匹配——如果希望全局强制执行,需确认如何配置。(2) 技能引用了个人(“Aaron”);确认该联系人在团队中是否有意义,或调整工作流文本。(3) 缺少source/homepage;如果需要发布者来源,验证所有者ID或获取内部版本的检查清单。(4) 由于仅是指令且不请求凭据,安装或环境变量泄露没有技术风险——可作为策略/检查清单文档处理,在启用自主调用前审查措辞以适应组织流程。...
详细分析 ▾
用途与能力
名称、描述和SKILL.md都描述了一个面向前端视觉工作的UX检查清单;未请求任何超出该用途范围的内容(无环境变量、无二进制文件、无安装)。轻微不一致:文档多次称其为“核心”和“始终激活”包,但注册表标志显示always: false——自动始终激活的声明未反映在元数据中。
指令范围
运行时指令是一份面向人类的检查清单和流程指导。它们不指示代理运行命令、读取文件、访问环境变量或向外部端点发送数据。唯一的非技术指令是在记录差距时“明确告知Aaron”(内部工作流指令,非技术操作)。
安装机制
无安装规范和代码文件——仅包含指令。没有任何内容写入磁盘,没有下载URL或包安装需要评估,风险较低。
凭证需求
技能声明不需要环境变量、凭据或配置路径。未请求过度访问权限。
持久化与权限
SKILL.md声称该包随设计审查自动激活并“始终激活”,但注册表标志未设置always: true。该技能可由用户调用并允许自主调用(平台默认);这种组合是正常的。如果期望它被强制用于所有代理,元数据中未反映这一点。
安全有层次,运行前请审查代码。

License

MIT-0

可自由使用、修改和再分发,无需署名。

运行时依赖

无特殊依赖

版本

latestv1.0.02026/3/21

初始版本——为所有视觉和前端工作建立核心UX标准。引入全面的检查清单,确保所有UI状态(数据、交互、表单、响应式、无障碍、边缘情况)在发布前都存在。要求在设计审查前运行检查清单,所有缺失的状态要么实施要么明确记录。区分快速检查(核心组件/功能)和完整检查(整页/流程)。强制每个屏幕的一致性质量,禁止静默状态遗漏。

● 无害

安装命令 点击复制

官方npx clawhub@latest install ux-baseline-check
镜像加速npx clawhub@latest install ux-baseline-check --registry https://cn.clawhub-mirror.com

技能文档

Core Pack — Always Active

This is a core skill. Apply it on ALL visual and frontend work alongside design-review. Every screen ships with ALL states covered. No exceptions. This is the minimum bar.

The State Inventory

Before any page or component is "done", verify each applicable state exists:

1. Data States

  • [ ] Empty — no data yet. Helpful message + clear CTA, not a blank screen
  • [ ] Loading — skeleton, spinner, or shimmer. Never a white flash
  • [ ] Loaded — the happy path, obviously
  • [ ] Error — API failure, network issue. User-friendly message + retry action
  • [ ] Partial — some data loaded, some failed. Don't hide what works
  • [ ] Long content — what happens with 200 items? 2000-character names? Test it

2. Interaction States

  • [ ] Hover — every clickable element has a hover state
  • [ ] Focus — keyboard navigation works, focus rings visible
  • [ ] Active/pressed — buttons respond to clicks visually
  • [ ] Disabled — grayed out with clear reason why (tooltip or helper text)
  • [ ] Selected — multi-select, current tab, active filter all visually distinct

3. Form States

  • [ ] Validation — inline errors on blur, not just on submit
  • [ ] Required fields — clearly marked
  • [ ] Success feedback — user knows their action worked (toast, inline, redirect)
  • [ ] Destructive confirmation — delete/remove actions require confirmation
  • [ ] Autofill — doesn't break layout when browser autofills

4. Responsive

  • [ ] Mobile (375px) — usable, not just visible. Touch targets ≥48px with ≥8px spacing between them
  • [ ] Tablet (768px) — layout adapts, not just shrinks
  • [ ] Desktop (1280px) — the primary target, looks intentional
  • [ ] Wide (1800px+) — content doesn't stretch absurdly. Max-width or centered

5. Accessibility

  • [ ] Keyboard nav — can reach all interactive elements with Tab
  • [ ] Screen reader — semantic HTML, aria-labels on icons, alt text on images
  • [ ] Color contrast — 4.5:1 minimum for text (use WebAIM checker)
  • [ ] No color-only indicators — don't rely solely on red/green for status

6. Edge Cases

  • [ ] First-time user — onboarding or empty state guides them
  • [ ] Permission denied — user sees why they can't access, not a broken page
  • [ ] Stale data — timestamps or refresh indicators when data might be outdated
  • [ ] Concurrent edits — what happens if two people edit the same thing?

How to Use

Run this checklist AFTER the feature works but BEFORE design review. For each missing state, either:

  • Implement it (preferred)
  • Document it as a known gap and tell Aaron explicitly

Never silently skip a state. If it's intentionally deferred, say so.

Quick Pass vs Full Pass

Quick pass (components, small features): States 1-2 only

Full pass (pages, flows, shipping features): All 6 sections

The Test

Ask yourself: "What happens if the network is slow, the data is weird, the user is on a phone, or they're using a keyboard?" If you don't know, you haven't finished.

数据来源:ClawHub ↗ · 中文优化:龙虾技能库
OpenClaw 技能定制 / 插件定制 / 私有工作流定制

免费技能或插件可能存在安全风险,如需更匹配、更安全的方案,建议联系付费定制

了解定制服务