页面看起来完整，不代表用户能顺利完成表单、用键盘导航或读懂失败原因。这个 Skill 用一组明确规则检查界面源码，适合在页面完成后找具体问题。它的默认产物是简洁的位置与问题说明，不是重新设计一套品牌视觉。
安装与首次使用
在项目根目录、已具备 Node.js 与 npm 的终端运行以下命令，给 Claude Code 安装这一项技能。使用 Codex 时，把 --agent claude-code 换成 --agent codex。这是项目级安装；安装完成后刷新或重开 Agent 会话，并在任务里明确写出技能名。
npx skills@latest add vercel-labs/agent-skills --skill web-design-guidelines --agent claude-code
给出文件和关键任务
以下是可按项目调整的首次输入：
使用 web-design-guidelines 审查 src/app/checkout/page.tsx 与相关表单组件。先读取最新规则，只报告问题，不改文件。优先检查键盘操作、字段标签、提交错误、焦点和移动端溢出；按文件给出行号，区分阻碍结账的问题与文字风格建议。
如果只说“看看网站怎么样”，Agent 还需要确定范围。更有效的输入是页面文件、相关组件和用户要完成的动作，例如填写收货地址并支付。这个 Skill 会先取最新的 Web Interface Guidelines，再检查指定文件；规则并非永远固定在本地安装包中，因此需要正常访问规则来源。
先处理让人卡住的问题
规则涵盖图标按钮名称、字段标签、可见焦点、语义元素、异步状态反馈，以及表单错误。对结账页而言，按钮是否只是一个可点击 div、错误出现后是否能定位到字段，往往比省略号样式更值得先修。让报告保留文件与行号，便于直接找到问题，而不是只写“需要提升可访问性”。
再看长内容、图片尺寸和布局：真实地址可能比示例长，弹层或固定页脚可能遮住焦点，图片没有尺寸可能挤动页面。动画与自动播放媒体也有减少动态效果和提供停止方式的要求。不要因为规则覆盖广，就顺手重写所有组件。
用一条用户路径给审查排序
先选用户真正要完成的事，例如结账页“输入地址 → 选择配送 → 提交订单”。每一步都要求 Agent 从源文件指出可定位的问题：输入框有没有可见标签、错误是否靠近字段且可读、按钮加载中是否反馈、键盘能否到达并看见焦点。规则文件会更新，因此阅读当前来源后再检查，不把以前记住的检查表当作最新全文。
源码审查结束后，优先修阻断任务的问题。比如字段错误只靠红色边框表达，会让一部分用户不知道哪里需要修改；比统一阴影样式更应先处理。报告要有文件与行号、用户会遇到的后果和具体建议。若标签由复用组件内部实现，追到组件核对，避免只看页面文件而误报。
把静态规则放进运行环境
修复后用键盘完整走一次目标任务，分别提交空值和无效值，再用窄屏与长文字检查溢出和遮挡。确认焦点不会被弹窗、固定页脚或动态提示吞掉。该 Skill 是有位置的源码审查入口；运行时布局、屏幕阅读器体验和完整无障碍符合性还需要相应测试。
另一个场景：筛选后没有结果
搜索页的空状态可以这样审查：“用户输入不存在的关键词后，页面是否明确说明没有匹配结果、保留输入值，并提供清除筛选的操作？加载中与真正无结果能否区分？请对相关组件按当前指南标文件与行号。” 验收不只是看一个截图：用键盘输入、提交、清除，再用屏幕较窄时检查提示是否被筛选栏遮住。若结果是异步更新，还要确认状态文字随结果变化，不把上一次结果的数量留在页面上。
视觉规则仍需具体设计目标
从空白项目做新页面时，先给清楚的视觉目标、参考页面、内容层级和可用资源，再用这个 Skill 审查生成的界面。社区里有人只装了设计规则与 React 规则就要求从零生成门户，得到的仍是普通界面。规则适合发现表单、层级和可用性问题，却不会替你决定品牌风格；首轮结果需要拿真实页面与设计目标逐项对照，再给 Agent 明确修改点。