--- name: design-context description: | Use when a request will produce frontend UI, a visual asset, an image prompt, or a video prompt, AND the intent/style is not already fully specified by the user or an existing design system in the repo. Forces a minimal, checkable design-context object to exist before generation so output does not default to generic/templated. Do NOT use for: single-property edits (color, spacing, copy tweak) with no ambiguity; bug fixes; refactors; or when the user already gave complete visual specs and you only need to execute. For those, just do the work. --- # design-context A **gate**, not a ceremony. Its only job: force a minimal, checkable design-context object to exist before any UI/visual/image/video generation, so the output does not fall back to template instinct (blue-purple gradient, Inter, fade-in, three feature cards). Keep it as cheap as the task allows. Depth lives in `references/` and loads only when needed. ## Step 0 — Size the task Decide depth before doing anything else. Default one level *down* if unsure — ceremony costs more than it saves below "feature" scale. | Size | Signal | Action | |---|---|---| | **Trivial** | single property / copy tweak, no ambiguity | Skip everything. Just do it. | | **Component** | one new component, or one asset; existing design system | Step 1 inline, no file. Then generate. | | **Page / feature** | a page, a section set, a feature | Step 1 + write `docs/design/design-context.md`. | | **System** | new brand, new product, multi-page | Full spec folder — see `references/design-spec-template.md`. | ## Step 1 — Minimum context gate (always, even Component-level) Before generating, this object must exist — from the user, from the repo (existing tokens / brand file), or inferred and labeled. Output it where the user can see and correct it. ```yaml goal: audience: vibe: [3-5 adjectives] accent_color: type: motion_intensity: <1-10> # 1-3 static, 4-7 fluid CSS, 8-10 choreography visual_density: <1-10> # 1 gallery-airy, 10 cockpit-dense reference: assumptions: [everything you inferred instead of being told] ``` Rules: - Ask **at most one** clarifying question. Everything else → fill with a labeled `assumptions` entry and proceed. A labeled guess the human can correct beats a silent guess they never see. - In a non-interactive pipeline: ask zero questions, fill every field as a labeled assumption. - Do not use adjectives without numbers. "premium" alone is rejected; convert to concrete comparisons (see `references/design-methodology.md` §1.2). ## Step 2 — Non-negotiable rules (apply by default, inline) 1. **One accent color per screen** — unless the brief is explicitly multi-brand; then document the rule. 2. **Easing:** `linear` for mass-less / steady-state motion (spinners, progress bars, uniform rotation, breathing glows); `cubic-bezier(0.16, 1, 0.3, 1)` for objects with implied mass entering/exiting. Never reversed. 3. **Rich / photographic / 3D motion → image sequence or video**, not hand-authored SVG path animation. SVG stays for icons, logos, line-art UI. See `references/asset-generation.md`. 4. **Animate only `transform` / `opacity`.** Never `width/height/top/left/margin` unless you have a documented reason (e.g. FLIP). Smooth pointer tracking goes through rAF, not directly in the event handler. Full reasoning: `references/design-methodology.md` §2.7. 5. **States match the element's actual risk** — a link ≠ a submit button. Reserve "done" for commits. Cover: default, hover, focus, active, disabled, loading, empty, error, success as applicable. 6. **Graceful-degradation ladder, not a single fallback:** image→placeholder/blurhash, font→system stack, video/Canvas-frame→`