메뉴
Turns a visual design into faithful, maintainable front-end code. Use when implementing a mockup or Figma file, matching a design spec, building against a design system, or reviewing how closely an implementation tracks its design.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Meta-skill that routes a task to the right engineering skill. Load this at the start of a session or when unsure which skill applies — it maps intent to the process that should govern the work.
Catches breaking changes between services before they ship, by testing the contract each consumer actually depends on instead of spinning up the whole system. Use when services deploy independently, when a provider API change could break a consumer, or when end-to-end integration tests are too slow and flaky to guard every service boundary.
Proves whether a change actually moves the metric, with a valid A/B test instead of a guess — a hypothesis, a primary metric, a pre-computed sample size, guardrail metrics, and an honest readout. Use when shipping a change meant to improve a number (conversion, retention, performance), running an A/B or holdout, or deciding whether a feature "worked."
Decouples deploy from release using feature flags — ship code dark, roll out gradually, kill instantly, and remove the flag once it's done. Use when releasing risky or large changes, rolling out by percentage/cohort, delivering A/B variants, or when stale flags are accumulating as debt.
Finds security risks at design time — before code exists — by mapping the system, enumerating how it could be attacked, and deciding what to do about each threat. Use when designing a feature that touches auth, data, money, or external input, when changing a trust boundary, or when a security-sensitive change needs a structured risk pass rather than a code-level review.
Designs durable, curated memory that an agent carries across sessions — what to persist, how to scope and retrieve it, and how to stop it from drifting or poisoning later runs. Use when an agent needs to remember decisions, preferences, or project facts beyond one context window, or when stale/over-generalized memory is corrupting its behavior.
| name | design-handoff |
| description | Turns a visual design into faithful, maintainable front-end code. Use when implementing a mockup or Figma file, matching a design spec, building against a design system, or reviewing how closely an implementation tracks its design. |
Translating a design into code is more than eyeballing the picture. Static frames hide states, breakpoints, semantics, and the token system underneath. Hardcoded hex values and one-off components look right on day one and drift off-brand by day thirty.
Extract the system behind the design, reuse what the product already has, implement every state the mockup doesn't show, and prove fidelity in the browser — not just in DevTools overlay.
Pairs with [[ui-craft]] for states and polish, [[accessibility]] for semantics, focus, and contrast the visual file won't specify, [[browser-checks]] to verify the running UI, [[incremental-delivery]] to ship slice by slice, and [[react-patterns]] when the handoff is React/Next.js. For gaps in the design, clarify before coding ([[spec-first]]) — don't guess missing behavior.
Skip as the primary skill for pure logic with no visual surface, or when intentionally diverging from design (experiments, internal tools with no spec) — still apply [[ui-craft]] and [[accessibility]] for user-facing output.
Work in order. Don't write layout CSS until you've mapped tokens and components.
Gather what the handoff actually includes — and what's missing.
From the design file / spec:
In the codebase:
Gap list — write explicit questions for the designer or PM before implementation:
Missing: empty cart state, error on failed payment, focus ring style, behavior below 375px,
loading skeleton vs spinner — need decision before build.
Unanswered gaps become expensive guesses in code.
Designs are built from a system even when the file doesn't label it. Extract:
| Layer | What to find | Map to code |
|---|---|---|
| Color | Primary, surface, border, text roles — not random hexes | --color-*, theme palette |
| Typography | Font family, sizes, weights, line heights | text-sm, heading-2, etc. |
| Spacing | 4/8px grid or explicit scale | space-4, gap-6 |
| Radii & borders | Corner radius, border width/color | token names |
| Elevation | Shadow levels | shadow-md, z-index scale |
| Breakpoints | Where layout changes | sm/md/lg definitions in code |
If Figma variables or styles exist, use them as the source of truth — they name the system. If the design uses raw values everywhere, propose token mappings and confirm with design before locking in.
Do not copy hex/spacing from inspect panel into component CSS without checking if a token already exists for that role.
If the design shows a button, card, or input you already ship — use the real component with the correct variant and size props.
// Prefer: system component + variant
<Button variant="primary" size="md">Save</Button>
// Not: new div styled to look like a button this week
<button className="bg-[#1a73e8] px-[18px] ...">Save</button>
When the design differs slightly from the existing component:
Button + icon slot) over fork.Forked near-copies drift — spacing, focus rings, and hover states diverge within weeks.
For elements that don't map to existing tokens, extract exact specs — don't approximate.
From Figma inspect / design spec:
Approximation is how implementations diverge. "About 16px" becomes 14px on the next screen. Round only when the design system scale already rounds that way.
Document new tokens in the theme/token file — not scattered in the component — so the next handoff reuses them.
Build the DOM structure and component hierarchy before pixel-perfect polish:
A pixel-perfect div stack that needs restructuring for a11y or state logic is wasted work. Structure
first, then tokens, then fine-tuning.
Slice vertically ([[incremental-delivery]]): one working section with real structure and one state before polishing the entire page.
The frame is one moment in time. The product has many ([[ui-craft]]). Plan and build:
| State | Often missing from mockups | Decide explicitly |
|---|---|---|
| Default / populated | Usually shown | — |
| Hover / focus / active / disabled | Rarely all shown | Match system interaction tokens |
| Loading | Often omitted | Skeleton vs spinner; preserve layout |
| Empty | Often omitted | Message, illustration, CTA |
| Error | Often omitted | Inline vs banner; recovery action |
| Partial / truncated | Rarely shown | Long title, many tags, overflow |
| Success / confirmation | Sometimes | Toast, inline check, next step |
If design didn't provide a state, implement from the design system pattern — don't ship blank or broken UI. Flag visual gaps to design for a follow-up polish pass.
A fixed-width mockup is a starting point. For each major breakpoint:
Implement and test at least:
Don't only pixel-match the artboard width and break everywhere else ([[browser-checks]]).
Visual handoffs rarely include focus order, labels, or contrast math — code still must deliver ([[accessibility]]):
prefers-reduced-motion for designed animationsIf design colors fail contrast, fix with design approval — don't ship illegible UI to match hex.
Semantic HTML and ARIA only where native semantics aren't enough — don't sacrifice structure for layout shortcuts.
Icons — prefer SVG from the system icon set; match designed size via width/height or token.
Don't rasterize icons as PNG unless the design requires it.
Images — export at appropriate resolution; use srcset/sizes for photos; explicit width/height
or aspect-ratio to prevent layout shift.
Fonts — load only weights used; subset if large; fallbacks that don't change metrics badly.
Motion — if the design specifies duration/easing, implement with CSS/transitions; document values as tokens. If unspecified, use system defaults. Gate decorative motion behind reduced-motion.
Export from Figma with consistent naming; avoid duplicate assets that differ by 1px.
"Looks close" is not done. Verify fidelity:
Reconcile differences deliberately:
| Difference | Action |
|---|---|
| Bug — doesn't match approved design | Fix code |
| Design system token vs raw mockup value | Use token; confirm with design if visible |
| Design gap — state never designed | Use system pattern; ticket for design |
| Intentional engineering constraint | Note in PR; don't silent drift |
Capture screenshot or recording for PR evidence.
When reviewing someone else's implementation:
Approve when faithful and maintainable — not when "close enough" with silent drift.
New page from full Figma frame
New variant on existing component
Design system drift — mockup uses raw values
No Figma — screenshot or PDF only
Retrofit old screen to new design
Design review before build (early handoff)