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.