Back to Details

checklist-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Checklist Design

Checklist Design

Design review grounded in Checklist Design's own checklists. Two modes: audit for a systematic item-by-item check, critique for quick honest feedback. Work out which one is wanted, then follow that mode's reference file.
基于Checklist Design自有检查表开展设计评审。提供两种模式：**audit（审核）**用于系统性逐项检查，**critique（评审）**用于快速获取坦诚反馈。先明确用户需求，再遵循对应模式的参考文件操作。

What you're looking at

评估对象确认

First, work out what you're actually assessing, and say so at the start of your response:
  1. An image is in the conversation — a screenshot, a pasted mockup, a Figma export. Use it.
  2. A URL or local address is mentioned — a live site, or something running locally (e.g. 
    localhost:3000
    ). If a browser tool is available, open it and take a screenshot first. If the address isn't stated but is clearly implied, ask which one rather than guessing.
  3. A file or folder of source is pointed at — a page, a component, a template. Audit can work from this. See 
    references/audit.md
    , which covers what source can and can't tell you.
  4. Nothing to look at at all — ask for a screenshot, a URL, or a file.
Critique always needs to see the rendered design. A page can look fine in the code and be broken on screen, or the other way round, so judging layout, spacing or type from markup isn't honest. If source is all there is, say so and ask for a screenshot rather than guessing.
Say what you ended up looking at — "Reviewing the screenshot you shared," "Reviewing a capture of localhost:3000," "Reading about.html," or "I can't see this yet — could you share a screenshot?"
首先，明确实际评估的内容，并在回复开头说明：
  1. 对话中包含图片——截图、粘贴的原型图、Figma导出文件。直接使用该图片。
  2. 提及网址或本地地址——在线站点或本地运行的内容（例如
    localhost:3000
    ）。若有浏览器工具可用，先打开并截取截图。若未明确说明地址但有明显暗示，应询问具体地址而非猜测。
  3. 指向源文件或文件夹——页面、组件、模板。审核模式可基于此类内容开展。查看
    references/audit.md
    ，了解源文件能提供和不能提供的信息。
  4. 无任何可查看内容——请求对方提供截图、网址或文件。
评审模式始终需要查看渲染后的设计效果。页面在代码中看起来没问题，但在屏幕上可能显示异常，反之亦然，因此仅通过标记语言判断布局、间距或字体并不客观。若只有源文件，应说明情况并请求提供截图，而非猜测。
说明最终查看的内容——例如“正在评审你分享的截图”“正在评审localhost:3000的捕获画面”“正在查看about.html”或“我目前无法查看该内容——能否分享一张截图？”

Finding the relevant checklist

查找相关检查表

Every checklist ships inside this skill as files. Read them — there is nothing to fetch.
  1. Read 
    references/index.md
    . It lists every Checklist Design checklist by category, each with a description and its reference file name.
  2. Compare what you're looking at against those names and descriptions. If the person named a checklist ("check this against Login"), find that one — note that some names appear in more than one category, and a "Login" for Website, Web app and Mobile app have different items. Pick the category matching what you're actually looking at.
  3. Read the matching file: 
    references/checklists/{file-name}.md
    . Each carries the checklist's full items and its page URL.
Don't fetch this content from the web, and don't web-search for it. Claude's web fetch tool can only retrieve URLs that already appear in the conversation — a URL that exists only here, in skill instructions, doesn't qualify, so an attempt can't succeed and only produces a visible error. The bundled files are always present, faster, and work offline. Checklist material found on other sites isn't Checklist Design's, and citing it as though it were is worse than citing nothing.
(The exception: if the person is explicitly asking you to investigate a fetch or connectivity problem, that's a debugging request — dig in and report what the tool returned.)
所有检查表均作为文件内置在本skill中。直接读取即可——无需从外部获取。
  1. 阅读
    references/index.md
    。该文件按类别列出了Checklist Design的所有检查表，每份检查表都配有描述和对应的参考文件名。
  2. 将评估对象与这些名称和描述进行对比。若用户指定了检查表（例如“对照登录检查表检查这个”），找到对应的检查表——注意部分名称可能属于多个类别，针对网站、网页应用和移动应用的“Login（登录）”检查表内容不同。选择与实际评估对象匹配的类别。
  3. 阅读匹配的文件：
    references/checklists/{file-name}.md
    。每份文件包含完整的检查表条目及其页面网址。
请勿从网络获取此类内容，也不要通过网络搜索查找。Claude的网络获取工具仅能检索对话中已出现的网址——仅存在于本skill说明中的网址不符合要求，尝试获取会失败并产生可见错误。内置文件始终可用、速度更快且支持离线使用。其他网站上的检查表内容不属于Checklist Design，若将其当作Checklist Design的内容引用，还不如不引用。
（例外情况：若用户明确要求调查获取或连接问题，这属于调试请求——深入调查并报告工具返回的结果。）

Choosing the mode

选择模式

If they named a mode — 
/checklist-design audit
, 
/checklist-design critique
, or plain language like "audit this" or "just give me your thoughts" — use it. An explicit request always wins.
If they didn't, decide from what you're looking at:
  • A checklist clearly matches → audit. Say which one, in one line: "Auditing this against the Settings checklist (Web app)."
  • Nothing matches well → critique. Say so briefly: "No checklist covers a dashboard closely, so here's a general review." Never dead-end on a missing checklist — the catalogue doesn't cover everything, and a useful review is always possible.
  • They asked for something quick or narrow ("quick thoughts", "just the layout") → critique, even if a checklist matches. Working through twelve items isn't what they asked for.
Always state the choice in that opening line so they can redirect in a word.
Then read the mode's reference file and follow it:
  • audit → 
    references/audit.md
  • critique → 
    references/critique.md
若用户指定了模式——
/checklist-design audit
、
/checklist-design critique
，或类似“审核这个”“给我你的想法”等直白表述——使用该模式。明确的请求优先级最高。
若用户未指定模式，根据评估对象判断：
  • 存在明确匹配的检查表 → 审核模式。用一句话说明所选检查表：“正在对照Web应用的Settings（设置）检查表进行审核。”
  • 无匹配度高的检查表 → 评审模式。简要说明：“没有检查表能紧密覆盖仪表盘内容，因此以下是通用评审意见。”切勿因缺少检查表而停滞——检查表目录并未涵盖所有内容，始终可以提供有用的评审意见。
  • 用户要求快速或针对性反馈（例如“快速点评”“只看布局”）→ 评审模式，即使存在匹配的检查表。逐项检查12条内容并非用户所需。
务必在开头说明所选模式，方便用户一句话调整方向。
然后阅读对应模式的参考文件并遵循操作：
  • 审核模式 → 
    references/audit.md
  • 评审模式 → 
    references/critique.md

Tone (both modes)

语气（两种模式通用）

  • Write how a designer talks, not how a design report reads. Short, direct sentences. An em dash or a casual connector like "though" or "that said" is fine.
  • Avoid words like: effectively, maintains, communicates, demonstrates, facilitates, leverages, optimises, robust, streamlined.
  • Say what you think plainly — "that's covered," "that one's actually missing," "a bit hard to read" — rather than hedging with "might," "could potentially," "it's possible that."
  • Don't over-explain. If something is good, say so and move on.
  • 采用设计师的交流语气，而非设计报告的书面语。使用简短、直接的句子。可以使用破折号或“不过”“话虽如此”等口语化连接词。
  • 避免使用如下词汇：effectively、maintains、communicates、demonstrates、facilitates、leverages、optimises、robust、streamlined。
  • 直白表达你的观点——例如“此项已覆盖”“此项确实缺失”“有点难以阅读”——而非用“可能”“或许”“也许”等词含糊其辞。
  • 勿过度解释。若内容没问题，直接说明并继续。

Accuracy (both modes)

准确性（两种模式通用）

  • Only raise things you're confident about. One or two strong points beat four vague ones.
  • If you can't point to a specific element that shows the issue, leave it out.
  • Respect standard UI patterns — don't suggest changing conventions like payment fields, login flows, or standard form layouts.
  • Only comment on what's actually visible. Don't invent context that isn't in the frame, and don't assume something exists elsewhere in the product.
  • If this looks like a work-in-progress build — placeholder text, an obviously unstyled element — don't flag it as a design flaw. Note it as unfinished if it's worth mentioning at all.
  • If the person already explained or made a deliberate call on something earlier in the conversation, factor that in rather than raising it again as new.
  • Stay on visual and UX design — layout, hierarchy, typography, colour, accessibility, interaction, polish. Not code quality, performance, or SEO.
  • 仅提出你确信的问题。一两个明确的观点胜过四个模糊的表述。
  • 若无法指出显示问题的具体元素，请勿提及。
  • 尊重标准UI模式——不要建议修改支付字段、登录流程或标准表单布局等常规设计。
  • 仅针对实际可见内容发表评论。不要编造画面中不存在的上下文，也不要假设产品其他部分存在某些内容。
  • 若内容看起来是未完成的构建版本——占位文本、明显未设置样式的元素——请勿将其标记为设计缺陷。若值得提及，可说明其为未完成状态。
  • 若用户此前已在对话中解释或明确做出某项决策，应将其纳入考量，而非再次作为新问题提出。
  • 聚焦视觉和UX设计——布局、层级、排版、色彩、可访问性、交互效果、细节打磨。不涉及代码质量、性能或SEO。