360 Secure SkillHub
360 安全技能中心

reference-design-contract

用于原型、改版或图像衍生前的规划阶段：读取用户提供的截图、参考链接、品牌文档或文字诉求，区分保留、调整与不可照抄的内容，冻结单一视觉方向，输出九段式 DESIGN.md、决策记录与实现交接文档，并附可选 HTML 预览与 P0 校验清单。

nexu-io
热度 15.20
最近更新 2026-10-19 02:44:02
分类：创作依赖：读写文件应用场景：UI 原型 / 品牌素材 / 模板

安装技能

复制下面的话术发给你的 Agent，它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill： npx secure-skills-cli add nexu-io/open-design/reference-design-contract
Metadata
name
reference-design-contract
zh_name
参考转设计合约
en_name
Reference Design Contract
description
Turn vague taste, screenshots, URLs, product notes, or "make it feel like this" references into a grounded DESIGN.md plus an implementation handoff. Use it before prototypes, decks, redesigns, or image remix work when the user needs a reusable visual direction rather than a one-off prompt.
triggers
["design contract","reference design brief","style contract","visual direction handoff","turn references into DESIGN.md","make it feel like this","做同款但不照抄","把参考图转成设计规范"]
od
{"mode":"design-system","platform":"desktop","scenario":"planning","category":"design-systems","preview":{"type":"html","entry":"example.html"},"design_system":{"requires":false,"generates":true,"sections":["visual-theme","color","typography","spacing","layout","components","motion","voice","anti-patterns"]},"craft":{"requires":["typography","color","anti-ai-slop"]},"inputs":[{"name":"brief","type":"string","required":true,"description":"Goal, audience, references, or the style problem to resolve"}],"outputs":{"primary":"DESIGN.md","secondary":["design-contract.md","implementation-handoff.md","example.html"]},"capabilities_required":["file_write"],"example_prompt":"Create a reference design contract for a developer-notes app. The direction should feel editorial, calm, tactile, and serious, but not copy any specific product. Produce DESIGN.md and an implementation handoff.","example_prompt_i18n":{"zh-CN":"为一个开发者笔记应用创建「参考转设计合约」。方向要有编辑感、安静、触感强、认真，但不要照抄任何具体产品。输出 DESIGN.md 和实现交接说明。"}}

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.

What this skill produces

Create three files:

  1. DESIGN.md — the reusable visual direction, following OpenDesign's standard nine-section design-system shape.
  2. design-contract.md — the decision record: evidence used, keep/change boundaries, rationale, risks, and quality gate.
  3. 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.

Workflow

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  6. 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
  7. 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
  8. Validate. Read references/checklist.md and satisfy every P0 gate before final handoff.

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.