brief

上下文： 此子技能是更广泛的 ui-craft 技能的一个视角。如果也安装了 ui-craft 技能，请先阅读其 SKILL.md，了解 Discovery + Anti-Slop + Craft Test，然后再应用以下特定视角。

继续之前，请先加载 references/brief.md，了解简报格式。

第 1 步：检测现有简报

检查 .ui-craft/brief.md 是否存在。使用 Read 或 ls 检查 .ui-craft/。

如果存在： 加载其内容。如果 $ARGUMENTS 指定了具体更新内容（例如“更新原则”“调整目标用户”“添加范围之外的事项”），则聚焦于该内容并跳过未变更的部分。否则，概述简报内容并询问：“你想更改什么？”

如果不存在： 继续第 2 步。同时检查仓库根目录中是否有 DESIGN.md 或 design-tokens.json（这是某些团队已采用的生态惯例）——如果有，请阅读并据此预填简报内容，而不是重新提问；注明信息来源。简报应补充现有的设计约定，绝不能与之冲突。

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

一次性引导用户填写五个必需部分。每个部分只问一个简短问题。除非用户要求深入探讨，否则不要分五次提问。

简洁提问模板：

“为了撰写设计简报，我需要了解五件事——回答可以尽量简短，结构由我来整理：

1. 产品目的 — 它做什么？用一句话说明。
2. 主要用户 — 用户的角色和使用场景是什么？
3. 原则 — 这个产品秉持什么理念？请给出三到五条立场。（如果还没有原则，请直说——我会带你完成原则工作坊。）
4. 成功指标 — 有什么可观察的行为能说明‘用户在此界面上成功了’？
5. 范围之外 — 列出三到五件此界面刻意不做的事。”

原则工作坊情形： 如果用户说“我还没有原则”或给出含糊的回答（例如“做好”“保持简单”），不要根据模糊输入杜撰原则。请先加载 references/principles-catalog.md。目录包含 8 类产品的 42 条经过实践的原则示例——将它们作为讨论的起点，而非直接套用的模板。从最接近用户产品类别的部分中展示 2-3 条，然后询问用户哪些认同、哪些想反过来。接着按 references/brief.md 中的流程开展原则工作坊，将其作为一个聚焦的子流程：询问用户过去讨论过的三个设计决策，然后根据其中的模式推导候选原则。拒绝接受空洞套话——要提出异议，并引导用户给出实质内容。

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

回答过于简略： 如果回答含糊到无法约束设计决策，请针对性地追问一个问题。每个部分最多追问两次，然后标记为未完成并继续。

第 3 步：写入前先展示

写入文件前，务必完整展示拟定的简报。询问：“这样看起来对吗？还有什么需要调整？”

未经确认，不要写入。

第 4 步：写入文件

如果 .ui-craft/ 不存在，则创建该目录。将确认后的内容写入 .ui-craft/brief.md。

文件必须包含 references/brief.md 中的五个确切标题。不得遗漏任何部分。

第 5 步：写入后

告知用户文件位于 .ui-craft/brief.md。建议提交该文件：

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

不要自动提交。根据项目规则，提交必须获得用户的明确指示。

约束

• 五个部分均为必填项。如果确实有一项未知，请将其写成带日期的占位符 [TO DEFINE — YYYY-MM-DD]，以便清楚地看出缺失之处。
• 更新时，简报应以追加为主。绝不要删除过去的内容；请注明弃用日期和原因。
• 用户的简报中不得出现品牌名称、产品示例或通用 SaaS 语言。简报描述的是他们的产品，而不是模板。

下一步： /tokens——简报决定意图，令牌将其编码（第 2 阶段）。