Back to Details

grill-me

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Step 0 — is the kit here? This skill reads files from the kit. Check once: 
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 the user 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.
The gates catch a screen built wrongly. Nothing in this repo catches a screen built correctly from the wrong brief, and that is where the expensive rework comes from: four eval runs scored 14/14 on the gates and still came back from 
/critique
as rework, every finding a decision no gate can see.
This command spends five minutes up front to remove that class of failure.
Target: 
$ARGUMENTS
(the thing about to be built; if that is not clear, that is itself the first question).
步骤 0——kit 在这里吗？ 此 skill 会从 kit 中读取文件。检查一次： 
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
或安装插件，然后停止。不要猜测任何 无法打开的文件内容。
这些 gate 能够拦截构建错误的页面。但 repo 中没有任何机制能拦截“依据错误需求简报构建出的正确页面”，而昂贵的返工正源于此：四次 eval 运行在 gate 上都得到 14/14，却仍然从 
/critique
得到返工结论；每一项发现都源于某个 gate 无法看见的决策。
该命令会预先花五分钟，消除这一类失败。
目标：
$ARGUMENTS
（即将构建的东西；如果目标不明确，这本身就是第一个问题）。

1. Read before you ask

1. 提问前先阅读

Asking for something the repo already answers is noise, and it teaches the user that answering you is a waste of time. Before writing a single question:
  • Look for an existing brief, 
    CLAUDE.md
    , 
    BRIEF.md
    , or a 
    reference/
    folder.
  • Look for an existing theme: 
    ${CLAUDE_SKILL_DIR}/../../../tokens/*.json
    , 
    design-tokens.json
    , 
    theme.css
    . If one exists, the theme question is answered — do not ask it.
  • Look at the neighbouring screens and components. Framework, conventions, and the component inventory are usually visible, not unknown.
Every question you keep after this pass is one the code genuinely cannot answer.
询问 repo 已经回答的问题只会制造噪声，还会让用户觉得回答你是在浪费时间。在写出第一个问题前：
  • 查找现有的需求简报、
    CLAUDE.md
    、
    BRIEF.md
    或 
    reference/
    文件夹。
  • 查找现有主题：
    ${CLAUDE_SKILL_DIR}/../../../tokens/*.json
    、
    design-tokens.json
    、
    theme.css
    。 如果主题已经存在，主题问题便已有答案——不要询问。
  • 查看相邻的页面和组件。框架、约定以及可用组件通常都清晰可见，并不属于未知信息。
经过这一轮排查后保留下来的每个问题，都应该是代码确实无法回答的问题。

2. The bank — grouped by what no gate can see

2. 问题库——按 gate 无法看见的事项分组

Pick from these. Do not ask all of them.
Purpose and lead
  • Who is this for, and what is the one task they came to finish?
  • What is the first thing their eye should land on? (Four equal cards means the answer is "nothing", and that is a composition bug before it is a design.)
  • What does success look like for them — what have they done when they leave?
Content reality
  • What does this look like with zero items? With one? With four hundred?
  • What is the longest string a real user will put in here — a 60-character project name, a nine-digit amount, an email with no spaces to break?
  • Which numbers are real and which are placeholder? Placeholder that ships as real is a lie the user catches immediately.
Irreversible actions
  • Which actions here destroy or cannot be undone, and what confirms them? (Destructive wears the danger variant in every place it appears — the trigger and the confirm dialog both. A blue Delete is an automatic fail.)
  • What happens when the action fails? What does the user read, and what can they do next?
Theme and platform
  • New theme or existing? If new: which direction, and does dark mode ship too?
  • What is the narrowest width this must survive? (The kit's floor is 280px.)
  • Which framework is the deliverable — and does it need RTL, AA or AAA?
Scope and done
  • How many screens or components exactly, and what is explicitly out of scope?
  • What has to be true before this is done: which gates, and is 
    /critique
    part of the bar or not?
从中选择问题，不要全部询问。
目的与首要焦点
  • 这是为谁构建的？他们前来要完成的那一项任务是什么？
  • 用户第一眼应该落在哪里？（四张同等醒目的卡片意味着没有任何视觉焦点，这在成为设计问题之前，就已经是构图错误。）
  • 对他们而言，成功是什么样子——离开时完成了什么，就算成功？
内容实际情况
  • 在零条、一条和四百条项目时分别是什么样子？
  • 真实用户会在此输入的最长字符串是什么——60 个字符的项目名、九位数的金额，还是没有空格可换行的 email 地址？
  • 哪些数字是真实的，哪些是占位内容？把占位内容当成真实内容发布，就是用户会立刻发现的谎言。
不可逆操作
  • 哪些操作会销毁数据或无法撤销，需要什么来确认？（危险操作在所有出现位置都应采用 danger 变体——触发器和确认对话框都要如此。蓝色的 Delete 会直接判定失败。）
  • 操作失败时会发生什么？用户会看到什么文案，下一步可以做什么？
主题与平台
  • 使用新主题还是现有主题？如果是新主题：方向是什么，是否也要提供深色模式？
  • 它至少要适配多窄的宽度？（kit 的下限是 280px。）
  • 交付物采用哪个框架——是否需要支持 RTL、AA 或 AAA？
范围与完成标准
  • 究竟要构建多少个页面或组件，明确不包括哪些内容？
  • 完成前必须满足哪些条件：必须通过哪些 gates，
    /critique
    是否属于验收标准？

3. The rule on asking

3. 提问规则

  • Maximum seven questions, asked in one round. A drip of one question at a time is worse than a wrong assumption.
  • Every question must change the work. If both answers produce the same build, it is not a question, it is a default — take it and say so.
  • Never ask what you can choose well. Taste is the job. Ask about intent, content, and constraint; decide the rest.
  • 最多提七个问题，并且在一轮中提出。 每次只零散地问一个问题，比作出错误假设更糟糕。
  • 每个问题都必须改变工作成果。 如果两种答案会产出相同结果，那就不是问题，而是默认值——采用默认值并说明。
  • 绝不要询问你可以自行妥善决定的事项。 审美判断是你的职责。询问意图、内容和约束；其余由你决定。

4. Everything unasked becomes a written assumption

4. 所有未询问的事项都要转化为书面假设

An assumption held silently is indistinguishable from a guess. Each one gets a line: what was assumed, the default taken, and what it costs if it is wrong.
Assumption: no dark mode requested -> shipping both anyway (the theme is already
dual, so the cost of including it is zero and the cost of retrofitting is not).
默默持有的假设与猜测毫无区别。每项假设都要写一行：假设了什么、采用了什么默认值，以及判断错误时会有什么代价。
假设：未要求深色模式 -> 仍同时交付两种模式（主题本身已支持双模式，因此加入的成本为零，而事后补加的成本并不为零）。

5. Output: a brief that can be checked later

5. 输出：一份日后可核查的需求简报

Write 
BRIEF.md
next to the work, in this shape:
undefined
在工作内容旁写入 
BRIEF.md
，格式如下：
undefined

<what is being built>

<正在构建的内容>

Goal one sentence, from the user's side User and task who, and the task they came to finish Deliverables exact list; N screens means N screens Lead the one thing the eye lands on first Content reality empty / one / many, longest string, real vs placeholder Irreversible which actions, what confirms them, what failure reads like Theme source of truth, dark mode, brand direction Platform floor narrowest width, framework, RTL, AA or AAA Out of scope what this is deliberately not Assumptions each with its default and its cost if wrong Done when the gates that must pass, and whether /critique is part of the bar

This file is the thing `/critique` and a later reviewer argue against. A brief
that lives only in the conversation cannot be checked, and so it will not be.
目标 站在用户视角的一句话 用户与任务 用户是谁，以及他们前来要完成的任务 交付物 精确清单；N 个页面就必须是 N 个页面 首要焦点 视线最先落在的一件事 内容实际情况 空 / 一 / 多，最长字符串，真实内容与占位内容 不可逆操作 哪些操作、如何确认，以及失败文案 主题 单一事实来源、深色模式、品牌方向 平台下限 最窄宽度、框架、RTL、AA 或 AAA 范围外 刻意不包含的内容 假设 每项均包含默认值及错误成本 完成标准 必须通过的 gates，以及 
/critique
是否纳入标准

该文件正是 `/critique` 和后续审查者据以提出异议的对象。只存在于对话中的需求简报无法被核查，因此也不会被核查。

6. Then build, then prove it

6. 然后构建，然后验证成果

/grill-me
-> build -> 
/gate
-> 
/critique
. This command removes ambiguity. It does not produce quality, it does not score anything, and it is not a substitute for rendering the work and looking at it.
/grill-me
-> 构建 -> 
/gate
-> 
/critique
。该命令用于消除歧义。它不会产出质量，不会进行评分，也不能替代实际渲染并查看成果。