Back to Details

critique

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
You are now running in a forked context. You cannot see the conversation that produced this work, you cannot ask the user a question, and nothing you learned elsewhere applies. Everything you need is below or on disk.
Step 0 — is the kit here?
bash
ls ${CLAUDE_SKILL_DIR}/../../../tokens >/dev/null 2>&1 && echo KIT_OK || echo KIT_MISSING
On 
KIT_MISSING
only the skill folders were installed, which is what 
npx skills add
does. Say so plainly, point at 
npx ux-ui-agent-skills init
or the plugin install, and stop. Do not guess the contents of a file you could not open.
Step 1 — take the critic's instructions, in full.
bash
cat ${CLAUDE_SKILL_DIR}/../../../.claude/agents/design-critic.md
That file is your brief: the stance, the three rules you never break, and the verdict format. Read it and follow it literally. If it is missing, say so and stop rather than improvising a critique — an unbriefed critic is a second opinion, not a review.
Step 2 — resolve the target.
Target: 
$ARGUMENTS
— a file or a directory.
You cannot ask. If 
$ARGUMENTS
is empty or names nothing that exists, say exactly what you were given, list what you would have accepted, and stop. A critique of a guessed target is worse than no critique, because it reads like a verdict on the real work.
Step 3 — refuse to critique blind.
A critique written from source alone is worthless. Render the target and look at it: screenshot every screen or harness at 1280 and 390 wide, light and dark, transitions off and the pointer parked off the UI. Then click every control and write down what actually changed. A control that changes nothing is a finding.
Step 4 — gather the numbers you will cite.
bash
KIT=${CLAUDE_SKILL_DIR}/../../..
node $KIT/scripts/taste_audit.mjs      <file> && node $KIT/scripts/taste_audit.mjs <file> --dark
node $KIT/scripts/slop_tells.mjs       <file> && node $KIT/scripts/slop_tells.mjs  <file> --dark
node $KIT/scripts/verify_overflow.mjs  <file|dir>
node $KIT/scripts/verify_responsive.mjs <file|dir> --scale=1.25
Report what they actually printed. These are heuristics: they name what you saw, they do not decide whether it is good. A clean run is not a defence: the kit's own seeded-defect fixtures pass every one of these gates, in both themes, and every one of them is work a senior designer would send back.
Step 5 — write the verdict.
In the format 
design-critic.md
specifies: the verdict, the three reasons a senior designer would send this back, and the findings table with evidence per finding. Name the file and the element. "The spacing feels off" is not a finding; "the card's 12px internal gap is the same as the 12px gap between cards, so the grouping reads as one block" is.
Do not soften it, and do not pad the "what is good" list to balance the tone.
Step 6 — state the scope, every time.
This is judgement, not measurement. It produces no percentage, and no percentage in this repo covers taste. Say so in the output.
你现在运行在一个分叉上下文中。你无法看到产生这项工作的对话，无法向用户提问，而且在其他地方学到的任何内容都不适用。你需要的一切都在下方或磁盘中。
步骤 0——kit 是否存在？
bash
ls ${CLAUDE_SKILL_DIR}/../../../tokens >/dev/null 2>&1 && echo KIT_OK || echo KIT_MISSING
如果出现 
KIT_MISSING
，说明只安装了 skill 文件夹，这正是 
npx skills add
所执行的操作。明确说明这一点，指向 
npx ux-ui-agent-skills init
或插件安装方式，然后停止。不要猜测无法打开的文件内容。
步骤 1——完整读取 critic 的指令。
bash
cat ${CLAUDE_SKILL_DIR}/../../../.claude/agents/design-critic.md
该文件就是你的任务简报，其中包含立场上限、三条绝不能违背的规则以及结论格式。阅读并严格遵循它。如果文件不存在，说明这一点并停止，不要即兴进行评审——没有简报依据的 critic 只是第二意见，而不是正式评审。
步骤 2——确定目标。
目标：
$ARGUMENTS
——一个文件或目录。
你不能提问。如果 
$ARGUMENTS
为空或指向的内容不存在，请准确说明你收到的目标，列出你本可接受的目标形式，然后停止。对猜测出来的目标进行评审比不评审更糟糕，因为它看起来像是对真实作品下了结论。
步骤 3——拒绝盲目评审。
仅根据源码写出的评审毫无价值。渲染并查看目标：在宽度为 1280 和 390 时，为每个界面或 harness 截图，同时覆盖浅色和深色主题，关闭过渡效果，并将指针停在 UI 之外。然后点击每个控件，并记录实际发生的变化。没有任何变化的控件就是一项问题。
步骤 4——收集将要引用的数据。
bash
KIT=${CLAUDE_SKILL_DIR}/../../..
node $KIT/scripts/taste_audit.mjs      <file> && node $KIT/scripts/taste_audit.mjs <file> --dark
node $KIT/scripts/slop_tells.mjs       <file> && node $KIT/scripts/slop_tells.mjs  <file> --dark
node $KIT/scripts/verify_overflow.mjs  <file|dir>
node $KIT/scripts/verify_responsive.mjs <file|dir> --scale=1.25
如实报告它们实际输出的内容。这些只是启发式检查：它们能够指出你看到的问题，却不能判断作品是否优秀。检查结果干净并不能成为辩护理由；该 kit 自身预置的缺陷 fixtures 在两种主题下都能通过所有这些 gate，而其中每一项都是资深设计师会要求返工的作品。
步骤 5——给出结论。
按照 
design-critic.md
规定的格式：给出结论、资深设计师会要求返工的三个理由，以及包含每项问题证据的 findings 表。指出具体文件和元素。“间距感觉不对”不是一项有效问题；“卡片的 12px 内部间距与卡片之间的 12px 间距相同，因此整个分组看起来像一个整体”才是有效问题。
不要弱化批评力度，也不要为了平衡语气而刻意扩充“优点”列表。
步骤 6——每次都要说明适用范围。
这是判断，而非测量。它不会产生百分比，而且本仓库中没有任何百分比能够衡量审美。必须在输出中明确说明这一点。

After the critique comes back

评审结果返回之后

For the session that invoked this skill, not for the fork:
Act on it. Fix every Critical and Major finding, re-run 
/gate
, and run this critique again on what changed. The loop ends when the remaining findings are Minor or Enhancement — not when you are tired of it.
Scoring the critic itself, rather than the work, is a maintainer task and lives with the harness in the kit's repository - not here. This skill installs into your project, and nothing it tells you to do should name a file your install does not have.
对于调用此 skill 的会话，而不是分叉上下文：
执行评审意见。修复每个 Critical 和 Major 问题，重新运行 
/gate
，并针对改动后的内容再次运行此评审。循环的结束条件是剩余问题均为 Minor 或 Enhancement，而不是你感到疲惫为止。
对 critic 本身进行评分，而不是对作品进行评分，是维护者的任务，应在 kit 的仓库中与 harness 一同处理，而不是在这里。此 skill 会安装到你的项目中，它指示你执行的任何操作，都不应涉及当前安装中不存在的文件。