在现有代码库中构建或重塑可访问 UI 时，遵循既有…

适用于需要构建或改造面向用户界面，并在既有设计系统、无障碍交互和渲染验证约束下完成实现的场景。

适用场景

解决思路

1. 构建或重塑面向用户的界面。
2. 不要虚构 PRODUCT.md 或 DESIGN.md。
3. 若存在现有 tokens 和根目录 DESIGN.md，遵循它们。
4. 不要安装动画库或 design-detector hooks。
5. 加载 frontend-design 获取视觉方向，加载 composition-patterns 获取可复用 API，加载 web-design-guidelines 获取 UI 代码检查清单。
6. 将长期任务记录在匹配的 MDX/README/DESIGN.md 中。
7. 明确任务、目标用户和界面模式：Operate（应用/任务）、Persuade（营销）或 Read（文档）。
8. 使用 brief、现有页面或明确指定的美学风格；如果仓库有 tokens 和共享组件，先检查这些。
9. 优先使用共享 primitives；在第二个调用点再做组合；不要为一次性路由抽取复合 API；不要把服务端数据提升到客户端 provider。
10. 采用移动优先布局、可见焦点、键盘路径和 prefers-reduced-motion；不要新增运动库。
11. 按适用情况覆盖 loading、empty、error、success 和 overflow。
12. 实现能完成任务的最小切片。
13. 同时检查桌面端和移动端；演练主要交互和键盘导航；批判性审视截图；将已证实的问题一批修复；最多再确认一遍后停止；如果缺少浏览器工具，要说明；type check 不等于视觉 QA。
14. 可选：针对现有 a11y 文档和测试运行 /w-a11y（不要虚构 WCAG 等级）；仅当已有 spec 覆盖该路径时才跑 Playwright E2E。
15. 文档：如果行为或命令有变化，运行 /w-docs。

适用边界 · 注意事项

• 仅规划不涉及 UI 的功能时，不使用本经验，留在 /w-plan。
• 仅安装 primitive 时，不使用本经验，留在 /w-shadcn。
• 缺少浏览器工具时无法完成渲染视觉验证；应明确说明，不能以 type check 代替视觉 QA。