eng-design

Enforces Compozy design tokens, primitives, and visual contracts for UI implementation and review.

2.7k|171|Updated Mar 28, 2026
One-click install
npx skills add https://github.com/compozy/compozy --skill eng-design
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: eng-design
Source: https://github.com/compozy/compozy/tree/main/.agents/skills/eng/eng-design
Command: npx skills add https://github.com/compozy/compozy --skill eng-design

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Compozy UI work drifts when contributors hardcode colors, re-implement shipped primitives, or copy prototype markup instead of following the canonical design system. This Skill centralizes the visual authority so production UI, static artifacts, and reviews stay consistent with tokens, components, and product voice.

Core Features & Use Cases

  • Canonical authority chain: Points to tokens.css, DESIGN.md, the @compozy/ui primitive inventory, component recipes, COPY.md, and PRODUCT.md as the sources of truth.
  • Reuse gate enforcement: Requires mapping every generic UI need to an exported @compozy/ui primitive before authoring new components, with lint-backed shadow-primitive prevention.
  • Visual contract handling: Defines how to implement from named OpenDesign references, treating them as normative for visual language but lossy for content, data, and component identity.
  • Use Case: When implementing a new dashboard panel from a mock, activate this Skill to map each region to shipped primitives, pull values from design tokens, and record authorized differences before claiming parity.

Quick Start

Use the eng-design skill to review my new settings panel component and verify it uses canonical tokens and @compozy/ui primitives.

Frequently Asked Questions about eng-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement a Compozy UI component from a design mock?

Activate the visual contract workflow: map every region of the mock to a shipped @compozy/ui primitive or domain composite, integrate it into the live host surface, and treat the reference as normative for visual language only. Record any authorized differences before claiming parity.

What is the source of truth for Compozy design tokens?

packages/ui/src/tokens.css is the canonical token source consumed by Tailwind v4. If DESIGN.md and runtime tokens disagree, treat tokens.css as source, run make codegen, and inspect the regenerated spec rather than editing generated regions.

Can I create a new UI component instead of reusing @compozy/ui primitives?

Only after the reuse gate: map the need against packages/ui/src/index.ts first. Redefining an exported name fails lint; generic primitives belong in packages/ui with story and test, while domain composites go in web/src/systems/<domain>/ with a domain-prefixed name.

Does Compozy UI support light mode or custom color palettes?

No. The design system is dark mode only with a warm-dark surface ramp and one accent target per viewport. Pull values from --color-*, --text-*, --radius-*, and --shadow-* tokens; hardcoded hex values or parallel palettes are prohibited.

What should I do when a design mock conflicts with runtime behavior?

Runtime truth wins. Remove unsupported controls or metrics the mock implies, record the contract conflict, and reconcile or explicitly authorize the reference delta before claiming parity with the visual contract.