Reference Design Contract

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:

• 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.

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.

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.