reference-design-contract

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Reference Design Contract

参考设计合约

Use this skill when the user has taste signals, references, or a rough "like this" request and needs a reusable design contract before generation. The goal is not to write a longer prompt. The goal is to make design decisions explicit enough that a later prototype, deck, redesign, or image-remix run can execute without guessing.

当用户有风格倾向、参考资料或大致的“做成这样”的需求，且需要在生成内容前制定一份可复用的设计合约时，可使用此技能。目标并非撰写更长的提示词，而是让设计决策足够明确，以便后续制作原型、演示文稿、重新设计或图像 remix 工作时无需猜测即可执行。

What this skill produces

该技能产出的内容

Create three files:

```
DESIGN.md
```
— the reusable visual direction, following Open Design's standard nine-section design-system shape.
```
design-contract.md
```
— the decision record: evidence used, keep/change boundaries, rationale, risks, and quality gate.
```
implementation-handoff.md
```
— concise build instructions for the next artifact-producing skill or coding agent.

If a preview is useful, also create

example.html

as a small hand-built contract preview. Do not make it the main deliverable.

创建三个文件：

```
DESIGN.md
```
— 可复用的视觉方向文档，遵循Open Design标准的九部分设计系统框架。
```
design-contract.md
```
— 决策记录：包含所用依据、保留/修改边界、理由、风险以及质量验收标准。
```
implementation-handoff.md
```
— 为后续生成产物的技能或编码Agent提供的简洁构建说明。

如果需要预览，还可创建

example.html

作为小型手工制作的合约预览，但不要将其作为主要交付物。

Workflow

工作流程

Lock the job. Identify target artifact type, audience, brand/product context, references, and constraints. Ask at most two questions only when a missing answer would change the direction. Otherwise choose a sensible default and label it as inferred.
Read evidence. Use provided screenshots, URLs, existing
```
DESIGN.md
```
, brand docs, image artifacts, or user notes. If evidence is missing, say so and base the contract on the brief only; do not invent brand facts.
Separate reference semantics. For every reference, split it into:
- ```
Keep
```
  : qualities to preserve, such as density, composition, material, typography rhythm, color temperature, or motion attitude.
- ```
Change
```
  : subject matter, copy, brand marks, exact layout, protected assets, and anything the user wants adapted.
- ```
Do not copy
```
  : literal screenshots, logos, claims, pricing, proprietary UI, or exact prompt wording from examples.
Freeze the direction. Choose one coherent visual stance. Do not provide five unrelated moodboards. If there are genuinely competing directions, name them briefly, pick the recommended one, and continue.

Write
DESIGN.md
. Use these nine headings exactly:

```
## 1. Visual Theme & Atmosphere
```
```
## 2. Color
```
```
## 3. Typography
```
```
## 4. Spacing & Grid
```
```
## 5. Layout & Composition
```
```
## 6. Components
```
```
## 7. Motion & Interaction
```
```
## 8. Voice & Brand
```
```
## 9. Anti-patterns
```

Write
design-contract.md
. Include:
- goal and target artifact
- evidence table with confidence (
```
observed
```
  ,
```
provided
```
  ,
```
inferred
```
  )
- keep/change/do-not-copy table
- final design stance in one paragraph
- risks and explicit unknowns
- quality gate checklist
Write
implementation-handoff.md
. Keep it short and operational:
- files to read
- token/palette/type/layout constraints
- asset rules
- responsive requirements
- "first artifact should prove..." acceptance notes
Validate. Read
```
references/checklist.md
```
and satisfy every P0 gate before final handoff.

锁定任务范围：明确目标产物类型、受众、品牌/产品背景、参考资料及约束条件。仅在缺失的答案会改变方向时，最多提出两个问题。否则选择合理的默认值并标注为推断结果。
研读依据：使用提供的截图、网址、现有
```
DESIGN.md
```
文档、品牌资料、图像产物或用户说明。如果缺少依据，需说明情况并仅基于简要描述制定合约；不得虚构品牌相关事实。
拆分参考语义：针对每一份参考资料，将其拆分为：
- ```
保留
```
  ：需要保留的特质，例如密度、构图、质感、排版节奏、色温或动效风格。
- ```
修改
```
  ：主题内容、文案、品牌标识、精确布局、受保护资产以及任何用户希望调整的内容。
- ```
禁止复制
```
  ：字面截图、标志、宣传语、定价、专有UI或示例中的精确提示词表述。
确定统一方向：选择一个连贯的视觉立场。不得提供五个无关的情绪板。如果确实存在相互竞争的方向，简要命名它们，选择推荐的方向并继续推进。

撰写
DESIGN.md
：严格使用以下九个标题：

```
## 1. 视觉主题与氛围
```
```
## 2. 色彩
```
```
## 3. 排版
```
```
## 4. 间距与网格
```
```
## 5. 布局与构图
```
```
## 6. 组件
```
```
## 7. 动效与交互
```
```
## 8. 语气与品牌
```
```
## 9. 反模式
```

撰写
design-contract.md
：包含：
- 目标与目标产物
- 依据表格（含可信度标注：
```
已观察
```
  、
```
已提供
```
  、
```
已推断
```
  ）
- 保留/修改/禁止复制表格
- 一段文字说明最终设计立场
- 风险与明确的未知项
- 质量验收标准清单
撰写
implementation-handoff.md
：保持简洁且具备可操作性：
- 需阅读的文件
- 令牌/调色板/排版/布局约束
- 资产规则
- 响应式要求
- “首个产物需验证……”的验收说明
验证：研读
```
references/checklist.md
```
并在最终交接前满足所有P0级验收标准。

Output rules

输出规则

Make every claim traceable to user input, observed reference evidence, or an explicitly labeled inference.
Prefer concrete constraints over adjectives: "one warm accent, no purple or blue glow" beats "premium".
Treat "do the same style" as "borrow controllable qualities", not "clone the original subject or prompt".
If the user asks for immediate UI generation too, finish these contract files first, then hand off to the appropriate artifact skill in the next step.

每一项声明都需可追溯到用户输入、已观察的参考依据或明确标注的推断结果。
优先使用具体约束而非形容词：例如“一种暖色调强调色，无紫色或蓝色光晕”优于“高端质感”。
将“采用相同风格”理解为“借鉴可控特质”，而非“克隆原始主题或提示词”。
如果用户同时要求立即生成UI，需先完成这些合约文件，再在下一步将任务交接给合适的产物生成技能。