build-design

Build design

Overview

Builds UI from a Figma file or design image so it matches the design, using the project's existing tokens and components. Reads the design at its source, builds with what the project already has, then compares.

When to Use

You have a Figma file or design image and need UI that matches it, built with the project's existing tokens and components.

This skill turns a design into code that matches it. It reads the design at its source, builds with what the project already has, then compares the result against the design before calling it done.

The design decides. Values come from the design file, never from your taste or a pattern you liked elsewhere. A change the design does not show is a deviation, and a deviation is the user's call.

It owns no domain rules. Where the design breaks one, build it as designed and report the conflict with its owner. Contrast is a requirement in better-accessibility and a measurement in better-colors. Focus and semantics are better-accessibility, type is better-typography and spacing and structure are better-layout. Palette is better-colors, copy is better-writing and surfaces, icons and motion are better-ui. Reviewing finished work is interface-review, exploring alternatives is variant and stress testing a component is break. The design decides; the floor does not. Before calling the build done, enforce hallmark's non-waivable Floor (tokenized primitives, accessible contrast, viewport boundaries) and impeccable's Craft Floor — a faithful build that violates the floor is still a defect.

Workflow

1. Read the skill principles and references for the current task scope.
2. Apply the rules to the actual interface, code, or design under review.
3. Document findings or changes with evidence (file:line, measured values).
4. Verify against the project's existing conventions and constraints.
5. Report or implement the fix, never silently changing stack or taste.

1. Read the design at its source