Back to Details

critique

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- AUTO-GENERATED. Do not edit here. Source: skills/ui-craft/ + commands/*.md. Regenerate with `node scripts/sync-harnesses.mjs`. -->
Context: this sub-skill is one lens of the broader 
ui-craft
skill. If the 
ui-craft
skill is also installed, read its SKILL.md first for Discovery + Anti-Slop + Craft Test, then apply the specific lens below.
Critique the UI at the target the user described through a design lens. Load the 
ui-craft
skill.
<!-- AUTO-GENERATED. Do not edit here. Source: skills/ui-craft/ + commands/*.md. Regenerate with `node scripts/sync-harnesses.mjs`. -->
背景说明: 此子技能是更广泛的
ui-craft
技能的一个视角。如果同时安装了
ui-craft
技能，请先阅读其SKILL.md中的Discovery（探索）、Anti-Slop（反冗余）和Craft Test（工艺测试）部分，再应用以下特定视角。
从设计视角对用户描述的目标UI进行评审。加载
ui-craft
技能。

Step 0: Visual capture (mandatory)

步骤0：视觉捕获（必填）

Code-only review is insufficient. Every audit/critique starts with the surface as the user sees it. Try the following in order; use the first one available:
  1. Playwright MCP — if 
    playwright
    MCP server is available, use it. Capture full-page screenshots at three viewports: desktop (1280×800), tablet (768×1024), mobile (375×812). Capture dark mode if the app supports it.
  2. Browser DevTools / Chrome MCP — second choice; same viewport set.
  3. Other browser automation (
    agent-browser
    , 
    cursor-ide-browser
    ) — third choice.
  4. Ask the user — last resort. If no automation is available, request screenshots from the user before proceeding. Be specific:
    • "Visual review needs screenshots. Please provide:
      • Full-page at 1280px (desktop)
      • Full-page at 768px (tablet)
      • Full-page at 375px (mobile)
      • Dark mode of each, if supported."
Do not begin the review until visuals are captured or provided. State this explicitly to the user when no automation succeeds — don't silently fall back to code-only review.
If the user declines to provide screenshots, run a code-only pass and clearly mark the report 
[CODE-ONLY REVIEW — visual issues not assessed]
at the top so the limitation is explicit.
Knob awareness (CRAFT_LEVEL sets the bar for what counts as "needs work"):
  • CRAFT_LEVEL 3
    → flag only anti-slop Critical items. Skip Minor polish.
  • CRAFT_LEVEL 5-7
    → flag Critical + Major. Mention Minor polish as optional.
  • CRAFT_LEVEL 9+
    → flag everything, including Minor polish and missing signature detail.
Run these lenses in order:
  1. Anti-Slop Test (from SKILL.md): flag every item present. Critical first (ALL CAPS, purple gradients, identical card grids, bounce easing, emoji icons, glassmorphism + neon). Then major (colored pills on trends, thick colored borders, uniform radii, gradient text, walls of text). Then minor (straight quotes, missing 
    tabular-nums
    , generic CTAs).
  2. Craft Test (from SKILL.md): where does the design fall short of "one accent, 3-5 placements; plain secondary text for comparisons; functional color only; every section earns its space"?
  3. Hierarchy: can the user tell what's primary, secondary, tertiary at a glance? Or does everything shout equally?
  4. Clarity: is the value prop legible in 5 seconds? Are CTAs specific (not "Learn more")?
  5. Signature detail: is there one memorable element that makes this feel designed, not assembled? If not, suggest one (motif, layout break, custom marker, distinctive hover).
  6. Inspiration gap — read 
    references/inspiration.md
    : which observed pattern from the archetypes / signature details applies here, and how does the current state diverge from it?
Output format — the Review Format table:
BeforeAfterWhy
Prioritize by impact, not by file order. End with a one-paragraph summary of the top 3 changes that would raise this from "AI-generated" to "designed".
Do NOT edit code. This is a critique.
仅代码评审是不够的。每一次审核/评审都从用户看到的界面外观开始。按以下顺序尝试，使用第一个可用的方式：
  1. Playwright MCP — 如果
    playwright
    MCP服务器可用，请使用它。在三种视口尺寸下捕获全页截图：桌面端（1280×800）、平板端（768×1024）、移动端（375×812）。如果应用支持深色模式，也需捕获该模式下的截图。
  2. 浏览器开发者工具 / Chrome MCP — 第二选择；使用相同的视口尺寸集。
  3. 其他浏览器自动化工具 (
    agent-browser
    , 
    cursor-ide-browser
    ) — 第三选择。
  4. 询问用户 — 最后手段。如果没有可用的自动化工具，请在继续前向用户请求截图。需明确说明：
    • "视觉评审需要截图，请提供：
      • 1280px尺寸下的全页截图（桌面端）
      • 768px尺寸下的全页截图（平板端）
      • 375px尺寸下的全页截图（移动端）
      • 若支持深色模式，请提供每种尺寸下的深色模式截图。"
在捕获或获取到视觉素材前，请勿开始评审。当所有自动化方式都失败时，请明确告知用户这一点——不要默认退回到仅代码评审。
如果用户拒绝提供截图，则进行仅代码评审，并在报告顶部明确标记
[CODE-ONLY REVIEW — visual issues not assessed]
，以说明此评审的局限性。
参数认知（CRAFT_LEVEL设定了“需要改进”的标准）:
  • CRAFT_LEVEL 3
    → 仅标记Anti-Slop中的严重问题。忽略次要优化项。
  • CRAFT_LEVEL 5-7
    → 标记严重和主要问题。将次要优化项列为可选提及内容。
  • CRAFT_LEVEL 9+
    → 标记所有问题，包括次要优化项和缺失的标志性细节。
按以下顺序应用评审视角：
  1. Anti-Slop测试（来自SKILL.md）：标记所有存在的问题。先标记严重问题（全大写文本、紫色渐变、相同卡片网格、弹跳缓动、表情图标、毛玻璃效果+霓虹风格）。然后是主要问题（跟风的彩色胶囊按钮、粗彩色边框、统一圆角、渐变文本、大段密集文本）。最后是次要问题（直引号、缺失
    tabular-nums
    、通用CTA按钮）。
  2. 工艺测试（来自SKILL.md）：设计在哪些方面未达到“一种强调色，3-5处使用；对比内容使用朴素次要文本；仅使用功能性颜色；每个区域都有存在的价值”的标准？
  3. 层级结构：用户能否一眼区分出主要、次要和三级内容？还是所有内容都同等突出？
  4. 清晰度：用户能否在5秒内读懂价值主张？CTA按钮是否明确（而非“了解更多”这类模糊表述）？
  5. 标志性细节：是否存在一个令人印象深刻的元素，让设计感觉是精心打造而非拼凑而成？如果没有，请提出一个建议（如主题图案、布局打破、自定义标记、独特的悬停效果）。
  6. 灵感差距 — 阅读
    references/inspiration.md
    ：哪些从原型/标志性细节中观察到的模式适用于此，当前设计与这些模式有何差异？
输出格式 — 评审格式表格：
BeforeAfterWhy
按影响优先级排序，而非文件顺序。结尾用一段文字总结前3项最关键的改进，这些改进可将设计从“AI生成”提升至“精心设计”水平。
请勿修改代码。这只是评审。