UI Reference Packs

ui-reference-packs

Use this skill after ui-design-contract only when UIDesigner needs a visual-system reference, product pattern, or style benchmark. It adapts OpenDesign's design-system and template catalogue into a small routed reference layer for HTML-first UI work.

This skill does not copy OpenDesign templates or brand systems. It helps choose a direction, then ui-design-executor turns that direction into original UI; load a design-system or deep renderer specialist only when separately triggered.

If ui-design-source has produced a frame/component handoff, use that handoff as stronger evidence than any reference pack. If an existing app already has clear tokens and components, skip this skill unless the user asks for a new style direction. If ui-live-artifact has not classified the task as live-ready or connected-live, do not select the live-artifact pattern.

Resource Map

Read only the relevant reference:

• Design-system packs — read when choosing a curated visual-system archetype.
• Pattern library — read when the user or design contract supports a specific page or artifact pattern.

Selection Workflow

1. Decide whether a pack is needed.
   • Use a pack when the user supplied references/brand material, asked for a style benchmark, the product has no clear visual system, or a broad pattern label must be accepted/rejected explicitly.
   • Skip packs when the screenshot or repo system already gives enough visual direction.
2. Start from the design contract.
   • Screenshot/page structure, user-provided constraints, and repo tokens outrank reference packs.
   • If no contract exists for a reference-heavy task, create one with ui-design-contract first.
3. Choose at most one primary design-system pack.
   • Optionally add one secondary influence for typography, density, or motion.
   • Do not blend many archetypes; blended taste turns generic quickly.
   • Use neutral archetype IDs in handoff notes instead of brand names.
4. Choose a page pattern only when the contract or user explicitly supports it.
   • Dashboard, kanban, pricing, mobile-frame, wireframe, and live-artifact patterns have narrow triggers.
   • A pattern is a structural permission, not a mandate.
5. Convert the chosen pack into UIDesigner tokens.
   • Color roles, type roles, spacing, radius, border, elevation, motion, and component behavior must be expressed in the local HTML/app system.
   • Do not copy logos, exact layouts, product claims, screenshots, or proprietary components.
6. Record the selection in the handoff.
   • Name the selected pack.
   • Explain why it fits.
   • State what was rejected and why.
   • Include any trigger guardrails, especially when not using a dashboard/kanban/pricing template.

Hard Guardrails

• Do not use a reference pack to override visible screenshot information architecture.
• Do not infer "dashboard" from "business", "admin", "analytics-looking", or a form category unless metrics/charts/tables/monitoring are visible or requested.
• Do not use named brands as imitation. Borrow controllable qualities such as density, typography rhythm, interaction attitude, and role structure.
• Treat any brand/source provenance as internal inspiration. In user-facing summaries, use the neutral archetype ID and concrete token decisions.
• Do not mention OpenDesign in the user-facing artifact unless provenance or implementation notes matter.
• Do not fetch or load every reference pack. Pick the smallest relevant reference file and continue.

Output Shape

When using this skill, include this compact note in the internal handoff or final summary when helpful:

## Reference Pack Choice
- Primary pack:
- Secondary influence:
- Pattern used:
- Why it fits:
- Rejected patterns:
- Token translation:
- Copy/brand safety: