AutoGineer
Generated banner for Build Design
Generated logo for Build Design

Build Design

Jakub KrehelCommunityCreated by Jakub Krehel

  • Skill
  • Workflow
  • Software development
  • MIT
  • No issues found
Download ZIP

From the author

Builds UI from a Figma file or a design image so it matches the design, using the project's existing tokens and components.
— the description by Jakub Krehel

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Build-design provides a structured process for translating visual designs into functional code. It emphasizes fidelity to the source design, requiring the agent to map design values to existing project tokens and components rather than introducing arbitrary styles. The workflow includes reading the design source, mapping values, implementing the UI, verifying the output through side-by-side comparison, and reporting any deviations, missing states, or domain conflicts.

What it does

  • Extracts design specifications from Figma files or image screenshots.
  • Maps design values to existing project tokens and component variants.
  • Implements UI components based strictly on provided design frames and breakpoints.
  • Performs a side-by-side visual comparison between the build and the design source.
  • Generates a detailed report of matches, deviations, unwired data, and missing states.
  • Identifies and reports domain conflicts where designs violate established rules.

When to use it

  • When you need to implement a new UI feature based on a Figma file or design mock-up.
  • When you need to ensure that new UI code strictly adheres to existing design tokens and component libraries.
  • When you need to audit a UI implementation against a design to identify discrepancies.
  • When you need to document missing states or backend requirements for a specific design.

Advantages

  • Ensures high fidelity between design intent and final implementation.
  • Prevents the introduction of arbitrary values or 'magic numbers' in the codebase.
  • Promotes the reuse of existing design tokens and components.
  • Provides clear, actionable reporting on implementation status and design deviations.
  • Maintains strict scope by focusing only on the elements defined in the design.

Usage examples

“Build the login page based on the latest Figma file.”
The agent will connect to Figma, extract the design values, map them to existing project tokens, implement the UI, and provide a report of the build status.
“Implement the header component using this screenshot as a reference.”
The agent will estimate dimensions from the image, map them to existing tokens, build the component, and report any deviations or missing states.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/jakubkrehel/build-design/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip build-design.zip -d .agents/skills

Documentation by Jakub Krehel

Build design

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.

1. Read the design at its source

A Figma link means the Figma MCP. Search the available and deferred tools for figma before saying it is unavailable, since the server often sits under a name you did not expect. A server that lists only an authenticate tool is connected but signed out, so ask the user to authenticate. With no Figma tool at all, ask the user to connect one, and do not build from memory or guesswork meanwhile. figma.md holds which tools to call and what each returns.

A screenshot or exported image has no values to read. Sizes are ratios to the capture, so state the scale you assumed and treat every measurement as an estimate. Ask for the Figma link when one exists, since it replaces the whole estimate.

Scope the run to the frames named. Frames that show the same thing at different widths are one piece at several breakpoints, not separate pieces.

This step is done when you hold a screenshot of every frame in scope and its values for spacing, size, radius, color, type and the components used. From a Figma file they are exact. From an image they are estimates at the scale you stated.

2. Map the design onto the project

Read the project's tokens and component library before writing anything. Then map every design value to what exists:

In the designIn code
A bound variable or styleThe token with the same name or the same value
A raw value that equals a tokenThat token
A raw value with no tokenThe nearest existing token, listed in the report as rounded
A component instanceThe project's component of that name, with the variant the design shows
A component instance with no project equivalentPlain markup in place, listed as a deviation, and ask whether a component should exist
A one-off group of layersPlain markup in place, not a new component

Never add a token, a component variant or an arbitrary value to hit a number. Stop and ask which way to go when rounding would visibly change the design. That means more than 2px on spacing or size, or a color landing on a different step.

Check what data the design needs and wire it to what exists. Where the backend for part of it does not exist yet, build that part as UI fed by props and name it in the report as unwired.

3. Build only what the design shows

Implement the frames, the breakpoints the frames define and the states the file draws, such as hover, empty or error. A state the file does not draw is not yours to design. Leave it to the existing component's default and list it as missing.

Leave everything around the piece as it was. No neighbouring copy edits, no icon swaps, no "while I was here" cleanups. A diff wider than the design is the most common way this goes wrong.

4. Compare against the design

Render the build at each frame's width beside the design screenshot and walk it element by element. Compare the properties Read the design at its source collected. "Gap is 12px, design is 16px" is a finding. "Feels a bit tight" is not.

With a browser at hand, screenshot each width and compare. Without one, hand over the local URL with the widths to check and say the comparison is unverified. Do not report a match you did not look at.

Fix every mismatch you caused, then compare again. This step is done when every remaining difference is a rounding or a question.

5. Report and stop

ElementDesignBuiltStatus
Card padding20pxp-5Matches
Title size15pxtext-sm, 14pxRounded to token
BadgeFilled pillText labelDeviates, asked: no badge component exists

Then list, one line each, and omit a list with nothing in it:

  • Unwired. What renders from props until the backend exists.

  • Missing states. What the design does not draw.

  • Domain conflicts. Where the design breaks a rule, with the owning skill.

Close by saying where the build is running and at which widths you compared.

Before you finish

You noticeFix
"Figma isn't connected" written before any tool searchSearch the tools for figma first
Values in code that appear in no Figma response, only in the screenshotRead them from the design context
An arbitrary utility such as w-[343px] or a raw hex in the diffMap it to a token, or ask if rounding shows
A new file under the components directory for a frame that is not a componentInline it as plain markup
A loading or error branch the design never drewRemove it, keep the default and list it as missing
Files in the diff that no frame touchesRevert them
A contrast or focus change the design does not showRestore the design and report the conflict with its owner
A comparison claimed with no screenshot of the buildRender each frame width, or say it is unverified
Hard-coded sample data with no mention in the reportList it under Unwired

Files

ATTRIBUTION.md

Attribution

This folder is an unmodified copy of the Agent Skill "build-design", distributed by AutoGineer (https://autogineer.com/agent-skills).

The skill's own files are unmodified copies. AutoGineer is not affiliated with or endorsed by the author or the publisher.

Files added by AutoGineer

  • ATTRIBUTION.md: this file, written by AutoGineer

  • LICENSE: copied from LICENSE

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Jakub Krehel
Publisher
Jakub Krehel (Community)
Source
jakubkrehel/skills · skills/build-design · commit f41f027
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Jakub Krehel or Jakub Krehel.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download build-design.zip