Sc:design Sync

Design Sync — design reference → matching code

Convert a design into code that matches the project's existing system, and keep the two in sync. The goal is parity and consistency: never hard-code a value you could pull from an existing token.

This skill is portable — it relies only on a design reference + the repo, so it works the same in Claude Code, Codex, and opencode/SquadCoder. It does not require any hosted design connector.

Step 0 — identify the design reference

Accept any of:

• Screenshot / image — read it directly (vision); measure spacing/sizes against a known element.
• Figma export — JSON/design-tokens (W3C tokens), SVG, or a CSS/Tailwind dump.
• Design-tokens file — tokens.json, theme.css, Style Dictionary, etc.
• A design URL — if reachable, fetch and read the rendered styles; otherwise ask for an export.

If nothing is provided, ask for one — do not invent a design.

Step 1 — read the project's design system FIRST (reuse > duplicate)

Before writing anything, inventory what already exists so you extend it instead of forking it:

• Token sources: tailwind.config.*, CSS custom properties (--color-*, --space-*), theme.*,

any tokens.json, or a design-system package.

• Existing components that resemble the target (buttons, cards, inputs) — match their API and styling.
• For SquadCoder/this repo: prefer the shared @squadcoder/ui primitives and the bundled

design-system / israeli-ui-design-system skills for token architecture and Hebrew typography.

Step 2 — extract design intent, then map to tokens

1. Pull the raw values from the reference: palette, type scale, spacing rhythm, radii, shadows,

breakpoints, states (hover/active/disabled/focus).

1. Map each raw value to the nearest existing token. Only mint a new token when there is a real

gap, and add it at the right layer (primitive → semantic → component), never inline.

1. Record the mapping (design value → token) so the sync is auditable and repeatable.

Step 3 — generate or update components

• Match the project's framework, file layout, naming, and import style (read a sibling first).
• Use logical CSS properties (ms-/me-/ps-/pe-/start/end, inset-inline-*) so the

result works in both LTR and RTL — never physical left/right for layout. Mirror directional icons.

• Use semantic HTML, real focus states, and the project's tokens for every color/space value.
• Keep components small and composable; one responsibility each.

Step 4 — verify visual parity (don't claim "pixel-perfect" blind)

• If Playwright/Chromium is available (it's bundled), render the component and screenshot it, then

compare against the reference at the same width. Check both an LTR and an RTL render for Hebrew.

• Check spacing rhythm, type scale, color, radii, and every interactive state.
• List remaining diffs honestly; fix or flag them. Do not assert parity you didn't verify.

Step 5 — report the sync

Output: the token mapping (Step 2), files created/changed, any new tokens added (and why), the parity check result (with the screenshot), and any intentional deviations.

Keeping in sync over time

• Treat the token mapping as the contract. When the design changes, re-run from Step 2 and update only

the tokens/components whose mapped values changed — don't rewrite untouched code.

• Prefer updating a token in one place over editing many call sites.

Guardrails

• Reuse existing tokens/components before adding new ones; flag duplication you find.
• Never inline magic numbers when a token exists.
• RTL/Hebrew is a first-class target, not an afterthought.
• Be honest about parity — verified vs estimated.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: squadcodercom
• Source: squadcodercom/squadcoder
• License: MIT
• Homepage: https://squadcoder.com

Install and usage instructions live in the source repository linked above.