brief

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

Load

references/brief.md

for the brief format before proceeding.

背景： 此子技能是更广泛的

ui-craft

技能的一个视角。如果同时安装了

ui-craft

技能，请先阅读其SKILL.md中的「探索+反废话+工艺测试」部分，再应用以下特定视角。

开始前，请加载

references/brief.md

了解简报格式。

Step 1: Detect existing brief

步骤1：检测现有简报

Check whether

.ui-craft/brief.md

exists. Use Read or ls on

.ui-craft/

If it exists: load its contents. If

$ARGUMENTS

names a specific update ("update principles", "shift target user", "add out of scope"), focus the session there and skip unchanged sections. Otherwise summarize what's in the brief and ask: "What do you want to change?"

If it doesn't exist: proceed to Step 2. Also check the repo root for a

DESIGN.md

design-tokens.json

(an ecosystem convention some teams already maintain) — if present, read it and pre-fill the brief's answers from it instead of re-asking; note the source. The brief complements an existing design contract, never contradicts it.

检查

.ui-craft/brief.md

是否存在。可对

.ui-craft/

目录使用Read或ls命令。

如果存在： 加载其内容。如果

$ARGUMENTS

指定了具体更新项（如「更新原则」「调整目标用户」「添加非适用范围」），则聚焦于该部分，跳过未变更的章节。否则总结简报中的内容并询问：「你想修改什么？」

如果不存在： 进入步骤2。同时检查仓库根目录是否有

DESIGN.md

或

design-tokens.json

（部分团队已采用的生态惯例）——如果存在，读取该文件并从中预填简报内容，无需重复询问；请注明来源。简报是对现有设计契约的补充，绝不能与之冲突。

Step 2: Draft a new brief (absent case)

步骤2：起草新简报（不存在的情况）

Walk the user through the five required sections in a single pass. Ask ONE compact question per section. Do not open five separate prompts unless the user asks for depth.

Compact prompt template:

"To write your design brief I need five things — answer as tersely as you like, I'll fill in structure:

Product purpose — what does it do, in one sentence?

Primary user — who, by role and context?

Principles — what does this product believe? Give me three to five stances it takes. (If you don't have these yet, say so — I'll run the principles workshop.)

Success metric — what does 'the user succeeded on this surface' look like in observable behavior?

Out of scope — three to five things this surface deliberately does NOT do."

Principles workshop case: if the user says "I don't have principles yet" or gives vague answers ("make it good", "keep it simple"), do NOT fabricate principles from vague input. Load

references/principles-catalog.md

first. The catalog has 42 worked example principles across 8 product categories — use them as conversation seeds, not as templates to adopt literally. Show 2-3 from the closest category to the user's product, then ask which resonate or which they'd flip. Then run the principles workshop from

references/brief.md

as a focused sub-flow: ask for three past design decisions that were debated, then derive candidate principles from the patterns. Refuse to accept platitudes — push back and prompt for substance.

Parsing long input: if the user provides a product description or PRD, parse it into the five sections rather than re-asking for information already given. State what you extracted and ask for confirmation or corrections.

Thin answers: if an answer is too vague to constrain a design decision, ask one targeted follow-up. Maximum two follow-ups per section before flagging it as incomplete and moving on.

一次性引导用户完成五个必填部分。每个部分仅提一个简洁的问题。除非用户要求深入展开，否则不要分五次单独提问。

简洁提示模板：

「要编写你的设计简报，我需要五方面信息——你可以尽量简洁地回答，我来整理结构：

Product purpose —— 用一句话说明这个产品的功能是什么？

Primary user —— 主要用户是谁，说明其角色和使用场景？

Principles —— 这个产品的核心理念是什么？请列出3-5个它秉持的立场。（如果你还没有这些理念，直接告诉我——我会启动原则工作坊。）

Success metric —— 从可观测的行为来看，「用户在这个界面上完成了目标」是什么样的？

Out of scope —— 列出3-5个这个界面刻意不提供的功能。」

原则工作坊场景： 如果用户说「我还没有设计原则」或给出模糊的回答（比如「做得好一点」「保持简洁」），不要根据模糊的输入编造原则。首先加载

references/principles-catalog.md

。该目录包含8个产品类别的42个现成原则示例——将它们用作对话引子，而非直接套用的模板。从与用户产品最接近的类别中挑选2-3个展示，然后询问哪些引起共鸣，哪些他们不认同。接着按照

references/brief.md

中的说明开展原则工作坊，作为一个聚焦的子流程：请用户举出三个过去曾引发争议的设计决策，然后从这些模式中推导候选原则。拒绝接受陈词滥调——要主动追问，引导用户给出实质性内容。

长输入解析场景： 如果用户提供了产品描述或PRD，将其解析到五个部分中，不要重复询问已经给出的信息。说明你提取的内容，并请用户确认或纠正。

回答过于简略场景： 如果答案太模糊，无法支撑设计决策，提出一个针对性的跟进问题。每个部分最多两次跟进，之后标记为未完成并继续下一步。

Step 3: Show before writing

步骤3：写入前确认

Always show the proposed brief in full before writing the file. Ask: "Does this look right, or anything to adjust?"

Do not write until confirmed.

写入文件前，务必完整展示拟议的简报内容。询问用户：「这样看起来对吗，有没有需要调整的地方？」

未经用户确认，不得写入文件。

Step 4: Write the file

步骤4：写入文件

Create

.ui-craft/

if it doesn't exist. Write the confirmed content to

.ui-craft/brief.md

The file must contain all five sections with the exact headings from

references/brief.md

. No omissions.

如果

.ui-craft/

目录不存在则创建。将确认后的内容写入

.ui-craft/brief.md

。

文件必须包含全部五个部分，标题需与

references/brief.md

中的标题完全一致，不得遗漏。

Step 5: After writing

步骤5：写入后

Tell the user the file is at

.ui-craft/brief.md

. Suggest committing it:

"Commit
.ui-craft/brief.md
to the repo — it's documentation, not config. The agent reads it every session."

Do not auto-commit. Per project rules, commits require explicit user instruction.

告知用户文件已存放在

.ui-craft/brief.md

路径下。建议提交该文件：

「将
.ui-craft/brief.md
提交到仓库——它是文档，不是配置。Agent每次会话都会读取该文件。」

不得自动提交。根据项目规则，提交操作需要用户明确指示。

Constraints

约束条件

All five sections are required. If one is genuinely unknown, write it as a dated placeholder with
```
[TO DEFINE — YYYY-MM-DD]
```
so the gap is visible.
The brief is append-mostly on updates. Never delete past content — mark deprecated with date and reason.
No brand names, product examples, or generic SaaS language inside the user's brief. The brief describes their product, not the template.

Next step:

/tokens

— the brief decides the intent, the tokens encode it (rung 2).

五个部分均为必填。如果某部分确实无法确定，使用带日期的占位符
```
[TO DEFINE — YYYY-MM-DD]
```
标注，确保缺口清晰可见。
简报更新以追加内容为主。永远不要删除过往内容——如需废弃旧内容，标注日期和原因。
用户的简报中不得出现品牌名、第三方产品示例或通用SaaS话术。简报描述的是他们自己的产品，而非模板。

下一步：

/tokens

—— 简报决定意图，tokens对其进行编码（第2阶）。