PIXEL-PERFECT · V10 · PROOF SHEET · 2026-10-13

An agent skill for Claude Code, Codex, Cursor, Grok, OpenCode, and Pi.

Your mockup is a picture. Ship the system inside it.

pixel-perfect is an agent skill that reads every frame of a high-fidelity mockup and turns it into real components in your framework: tokens, atoms, molecules, organisms, and screens. Each layer is checked against the frames it came from before the next layer starts. After that, every new screen, from a mock or a single sentence, is built from the parts you already have.

Install pixel-perfect: fetch and follow https://github.com/hackerpug-ai/pixel-perfect/INSTALL.md

Paste into any of the six agents.

npx skills add hackerpug-ai/pixel-perfect
  • MIT
  • by Justin Rich
  • View source 
  • Works in six agents
  • Frameworks: SvelteKit, React, Expo, SwiftUI, GPUI, Ratatui, and any stack with a docs URL
The install card as drawn in the design
The install card as drawn in the design
Install pixel-perfect: fetch and follow https://github.com/hackerpug-ai/pixel-perfect/INSTALL.md

Paste into any of the six agents.

Install pixel-perfect: fetch and follow https://github.com/hackerpug-ai/pixel-perfect/INSTALL.md

Paste into any of the six agents.

DESIGN FRAME BUILT COMPONENT
Drag to compare the design frame with the component built from it. The corner marks line up when they match.
FIG. 1  One mockup, separated into five layers. Each layer is built and checked before the next.

Designs die in translation.

You paste a screenshot into your agent and say "build this." The first screen comes out well. The second screen's card has different padding, a gray that isn't in the design, and a button that's almost the same. Nobody wrote down which colors are tokens, so the agent guessed.

Six weeks later there are four slightly different cards and no way to say which one is correct. The mockup is still right. The code drifted, one screen at a time.

APPROVED
Install pixel-perfect: fetch and follow https://github.com/hackerpug-ai/pixel-perfect/INSTALL.md

Paste into any of the six agents.

DRIFTED
Install pixel-perfect: fetch and follow https://github.com/hackerpug-ai/pixel-perfect/INSTALL.md

Paste into any of the six agents.

1234
  1. 1 Padding 20 instead of 16.
  2. 2 An invented gray, #8A8F96, not in the tokens.
  3. 3 A fifth button style.
  4. 4 Border radius 5 instead of 4.
Example drift, applied to a real component from this build.

Your design survives your codebase.

Consistency through composability

Every screen is assembled from the same parts, so one card can't quietly become four.

Make it real

No mockup step, no spec format, no throwaway files. The design is the reference, and the code in your repository is the deliverable.

Rapid iteration

Add a screen with one sentence, and it's built from the parts you already have. Change a token and it flows everywhere. Change a component and everything built on it re-checks.

Language agnostic

Works in whatever UI stack you use. Storybook if you want it, a native sandbox if you don't.

From mockup to system in four commands.

Point it at the design, scaffold a sandbox, build the layers, and read the report. Each layer is checked against its frames — a pass needs a real PNG — before the next one starts, so the report is the proof.

  1. STEP 1 · READ THE DESIGN
    /pixel-perfect:init my designs are in design/deck.html

    Finds the frames, detects your framework, writes the manifest.

    design/manifest.json (excerpt) This build
    {
      "spec": "../.spec/prds/landing/strategy.md",
      "references": [6 design files],
      "framework": "sveltekit",
      "sandbox": "storybook",
      "platforms": ["web-desktop", "web-mobile"]
  2. STEP 2 · SCAFFOLD THE SANDBOX
    /pixel-perfect:scaffold

    A component browser in your framework, with the token stories already in it.

    terminal This build
    created  src/app.css
    created  .storybook/main.ts
    created  src/lib/design-system/Colors.stories.svelte
    created  src/lib/design-system/Typography.stories.svelte
    sandbox  http://localhost:6006
  3. STEP 3 · BUILD THE LAYERS
    /pixel-perfect:build

    Writes the inventory first. Every item names the frames that justify it and the parts it composes. Then it builds, bottom layer first.

    design/inventory.json (excerpt) This build
    "atoms": [
      { "name": "Button",
        "appears_on": ["pixel-perfect-landing-dc/01", … 17 frames] }, …
    "molecules": [
      { "name": "CopyBlock",
        "composes": ["InlineCode", "Button"],
        "appears_on": ["pixel-perfect-landing-dc/01", … 10 frames] }, …
  4. STEP 4 · CHECK THE PROOF
    /pixel-perfect:status

    Every layer gate needs a real PNG, and only the gate writes a pass. When precision matters, verify sends a packaged judge to compare each render with its frame.

    status This build
    tokens      25 colours
    atoms     gate passed  22 components
    molecules gate passed  19 components
    organisms gate passed  15 components
    screens   gate passed  2 components
terminal recording
Recorded run, sped up: build, then status. 13 minutes in 66 seconds.

A terminal recording of pixel-perfect running build, then status.

Tokens
10.0M
Minutes
341
Frames
22
Gates
34
Components
56

Measured on this site's own build. Tokens counts new tokens; see the FAQ.

No mockup yet? wireframe turns a PRD into wireframes that build reads the same way.

It brings its own agents.

Batteries included: the plugin ships a designer and a judge, started by its workflows with a brief — no agent wiring of your own. The designer builds each component in your stack; when you ask verify for it, the judge compares each render to its frame, and with --fix a failing component goes back to its builder. The designer's craft guidance is Claude's frontend-design skill , built in.

Your next screen starts from the parts you already have.

The system is the deliverable, so it keeps going. Describe a page, or drop in a new mock, and the agent reuses what exists before it invents anything.

YOU /pixel-perfect:evolve "add a changelog page"
AGENT

EVOLVE proved — add Changelog · SiteHeader+home · TouchList+inline code · check clean · 0 pre-existing goldens moved

reuse 6·new 1·0 captured components moved

/changelog

This thread is the recorded run.
evolve with a new mock

Sorts each element into reuse, variant, new, promote, or remove, with an orphan sweep for removals. Confirms once. Proves by re-capture.

refine with a token change

Change a token. Every component that uses it updates, and the gates confirm nothing else moved.

Cascades into (accent-text): Button, TextLink, PlateLabel, 33 more
add-platform

The same system on a second platform, built from the same inventory.

It writes a DESIGN.md too.

A plain document of your tokens and components, kept current on every build, so your other tools and your teammates read the same system.

Install pixel-perfect
DESIGN.md · GENERATED · EXAMPLE
design system
## tokens
color.ink#111316
color.accent#E0007A
space.416px
radius.sm4px
## components
Buttonprimary, secondary
PlanCardcomposes Heading, Price, Button
Headercomposes Logo, NavLink

Install it in your agent.

View source 

Read the skill before you install it. It's a folder of markdown and scripts in the open.

Install pixel-perfect: fetch and follow https://github.com/hackerpug-ai/pixel-perfect/INSTALL.md

Paste into any of the six agents.

npx skills add hackerpug-ai/pixel-perfect
/plugin marketplace add hackerpug-ai/pixel-perfect
/plugin install pixel-perfect@pixel-perfect

Next: open a project that has your design and run /pixel-perfect:init.

Releases are version-locked across all six agents. Every breaking release ships an upgrade guide.

What it touches

READS
  • Your design files or URL
  • package.json and the framework config
  • DESIGN.md, if one exists
WRITES
  • Components in your source tree
  • Sandbox stories
  • design/ and DESIGN.md
RUNS
  • Your package manager
  • A headless browser, for capture
  • Your existing lint and test scripts

Questions

Why not just prompt my agent?

Prompting works for one screen and breaks on the second. The agent has no record of which values are tokens and which parts already exist, so each screen is a fresh guess. pixel-perfect writes that record down as code, then checks every new layer against the design before moving on.

What happens when the design changes?

Run evolve with the new mock. Each element is sorted into reuse, variant, new, promote, or remove, you confirm once, and a re-capture shows exactly which components moved.

How many tokens does it use?

This site's own build read a 22-frame design and used 10.0M new tokens across 341 active minutes, plus 449.4M tokens of cached context re-read between turns. Frames are read once and cached, so evolve and refine runs cost a fraction of the first build.

Does it work with my stack?

If your stack has a docs URL, yes. SvelteKit, React, Expo, SwiftUI, GPUI, and Ratatui have been built with it. Where Storybook doesn't run, it generates a native sandbox in your framework instead.

Will it lock me in?

No. The output is plain code in your repository plus a DESIGN.md. Delete the skill and everything it built still works, because nothing depends on it at runtime.

It's at version 10. Is it stable?

The command surface is stable and version-locked across all six agents. The major number counts breaking changes to the inventory format, and each one ships with an upgrade guide.

Don't gates make this slow?

They make the next step faster. A gate runs once per layer, so every layer is built on parts that already match, and later changes are cheap: change a token, every component that uses it updates, and the gates confirm nothing else moved.

How is this different from v0, Claude Design, or Figma's MCP?

Those produce the design. pixel-perfect starts where they stop: it takes their output as input and turns it into a component system in your repository that keeps growing with every screen.

Your next mockup has a system inside it.