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:

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.