---
name: frontend-design-review
description: 在确定或审查前端页面、落地页、作品集和重新设计的视觉方向时使用；区分只读审查、方向建议和已授权实现，并用真实截图或渲染验证视觉结论。不用于纯业务逻辑、状态管理或已经有明确设计稿的机械实现。
---

# 前端设计读题与审查

## 工作模式

- **review**：默认模式。只报告具体视觉、层级、品牌和可用性问题，不修改文件。
- **direction**：给出一个推荐方向、关键设计语言和必要取舍，不生成多套泛化主题。
- **implement**：仅在用户明确要求修改页面时进入。沿用项目设计系统，修改后用实际渲染或截图复核。

## 最小流程

1. 确认模式、页面类型、受众、已有设计系统和用户给出的参考；只检查视觉外观时，不扩展到数据流或业务逻辑。
2. 用一句话声明页面理解和约束。若两个方向会产生实质不同结果，只问一个能决定方向的问题。
3. review/direction 模式按需阅读 [审查与方向启发](references/review-heuristics.md)，只使用与当前页面有关的检查项。
4. review 模式基于真实截图、渲染结果或明确的代码位置排序问题；无法看到页面时说明证据缺口，不把代码推断写成已观察事实。
5. direction 模式只推荐一个方向，并解释它如何服务受众、品牌和使用频率。
6. implement 模式先记录现状和约束，再做最小修改；使用任何可用浏览器或渲染工具检查主要桌面视口、窄屏、溢出、遮挡、键盘焦点和关键交互状态。

如果用户给了明确设计稿且只要求机械实现，或问题只涉及 API、状态管理和业务逻辑，不使用本技能。后台工具仅需常规密度和可用性修正时，优先遵循项目已有设计系统。

## 输出要求

- review：页面理解、按影响排序的问题、证据位置和最小建议。
- direction：一个推荐方向、适用理由和关键设计变量；只有具体限制会改变选择时才说明。
- implement：修改内容、实际渲染视口和结果、未检查状态。

避免泛泛说“更现代”“更高级”；建议要落到布局、层级、颜色、字体、动效、资产或文案。没有实际渲染证据时，只能报告代码层修改，不能声称视觉结果已验证。