ui-validator
UI Validator
铁律:没有真实渲染证据,就不能宣布 UI 改动完成。
工作流
- Step 1: 开发环境自检 ⚠️ REQUIRED
- 1.1 先确认目标服务是否已启动,避免重复拉起开发服务器。
- 1.2 明确要访问的页面、组件演示路径或交互入口。
- Step 2: 执行浏览器验证 ⚠️ REQUIRED
- 2.1 至少检查默认主题和暗色模式。
- 2.2 必要时检查移动端与桌面端视口。
- 2.3 对关键交互执行点击、悬停、输入或状态切换。
- Step 3: 留证据
- 3.1 优先使用截图、可访问性快照或计算样式值作为证据。
- 3.2 记录问题发生条件,而不是只说“样式不对”。
- Step 4: 回归结论
- 4.1 明确哪些场景通过、哪些仍有问题。
- 4.2 如果发现回归,反馈到前端实现阶段处理。
重点检查
- light / dark 模式。
- desktop / mobile 布局。
- 关键交互状态。
- 对比度、间距、圆角、层级、溢出和禁用态。
反模式
- 不开页面,只读代码就宣布 UI 正常。
- 只看一张截图,不验证交互状态。
- 不说明问题发生条件和视口尺寸。
交付前检查
- 已在真实页面验证关键场景。
- 已留截图、快照或样式值证据。
- 已覆盖至少两种主题或关键视口。
- 结论中明确了通过项与残余问题。
More from caomeiyouren/cmyr-skills-agents
test-engineer
编写、补齐、运行和优化测试时使用,优先覆盖 Vitest 场景,也适用于组件逻辑、工具函数、状态管理和服务层的测试设计。用户提到 test、unit test、integration test、coverage、mock、Vitest、补测试时都应触发。
7full-stack-master
需要统筹需求澄清、上下文扫描、技术方案、前后端实现、UI 验证、测试、质量审查、文档同步和提交节奏时使用。它负责编排多技能协作,而不是亲自替代所有专业技能。用户提到 end-to-end workflow、全流程开发、从需求到提交、PDTFC+、多技能编排时都应触发。
7quality-guardian
运行并解读 lint、类型检查、测试等质量门时使用。它不只是执行命令,还要根据变更范围选择最小充分检查、分析失败原因,并给出是否允许继续提交或发布的判断。用户提到 lint、typecheck、tests、quality gate、验证改动时都应触发。
6git-flow-manager
管理暂存策略、拆分提交、检查变更边界、维护提交顺序、生成变更记录和预判冲突时使用。适合多步交付而不只是单次 commit message 生成。用户提到 staging、split commits、git flow、changelog、release prep、冲突预警时都应触发。
6conventional-committer
需要生成 Conventional Commit 提交消息并执行单次提交时使用。适用于 feat、fix、docs、refactor、test、build、ci、chore 等常规提交场景。先检查质量门,再分析 diff,再生成符合 commitlint 预期的消息。
6context-analyzer
在动手规划、修改、调试或回答复杂项目问题前使用。用于快速扫描项目结构、依赖、约束文档、关键文件和调用链,输出任务相关上下文,而不是直接改代码。用户提到 analyze context、scan repo、understand project、定位实现、找规范、排查调用链时都应触发。
5