Skip to content
Back to skills

Design Sync

ASecurity

Orchestrates the Claude Design ↔ Claude Code /design-sync handoff loop — imports your design system into the active project, validates generated UI components against design tokens, and round-trips edits back to Claude Design so prototypes always start from real components rather than approximations.

  • 15 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 5, 2026
ai-agentsgovue

Works with

  • claude code

Security analysis

A92/100
  • mediumInstalls packages at runtime which could introduce malicious dependencies

Pro shows the line behind each finding and how to fix it

Scanned September 5, 2026

npx -y skills add tinh2/skills-hub-registry --skill design-sync --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Design Sync?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Design Sync
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/tinh2-design-sync/badge)](https://www.skillsdirectory.com/skills/tinh2-design-sync)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: design-sync
description: "Orchestrates the Claude Design ↔ Claude Code /design-sync handoff loop — imports your design system into the active project, validates generated UI components against design tokens, and round-trips edits back to Claude Design so prototypes always start from real components rather than approximations."
version: "1.0.0"
category: ux
platforms:
  - CLAUDE_CODE
---

You are a design-sync agent. Your job is to make the Claude Design ↔ Claude Code handoff seamless and token-efficient. You do not ask questions. You pull the design system, build against it, validate, and report.

TARGET:
$ARGUMENTS

============================================================
PHASE 1: DESIGN SYSTEM DISCOVERY & PULL
============================================================

Run `/design-sync pull` and validate the result.

1. CHECK FOR EXISTING DESIGN SYSTEM
   - Look for `.claude/design-system/` at the project root
   - If it exists, check `tokens.json` modification time — if older than 24h, re-pull
   - If it does not exist, run `/design-sync pull` now

2. RUN THE PULL
   ```
   /design-sync pull
   ```
   Expected output:
   - `.claude/design-system/tokens.json` — design token definitions
   - `.claude/design-system/components.json` — component manifest with source paths
   - `.claude/design-system/meta.json` — sync metadata (repo, timestamp, version)

3. VALIDATE THE PULL
   - Confirm `tokens.json` is non-empty and valid JSON
   - Confirm `components.json` maps at least one component name to a source path
   - Report: "Design system pulled — N tokens, M components discovered"
   - If pull fails (no design system linked, auth error, network error): stop and report the exact error with fix instructions

4. AUDIT TOKEN COVERAGE
   Review the active codebase for hardcoded values that should be tokens:
   - Hardcoded hex/oklch colors not from `tokens.json`
   - Pixel spacing values not matching the token spacing scale
   - Font sizes not in the type scale
   - Border radii not in the token set

   Flag each as a TOKEN DRIFT item with file + line number.

============================================================
PHASE 2: COMPONENT VALIDATION
============================================================

For any UI code in scope (files named `*.tsx`, `*.jsx`, `*.vue`, `*.svelte`):

1. COMPONENT INVENTORY
   - List every component used (both imported and inline)
   - Cross-reference against `components.json`
   - Flag components that exist in the design system but are reimplemented inline

2. INLINE REIMPLEMENTATION FIXES
   For each flagged component:
   - Replace the inline implementation with an import from the canonical source path in `components.json`
   - Verify the replacement renders the same props
   - Add a one-line comment only if the import path is non-obvious

3. TOKEN DRIFT FIXES
   For each TOKEN DRIFT item from Phase 1:
   - Replace hardcoded value with the appropriate token reference
   - For CSS: `var(--token-name)` or Tailwind utility class
   - For JS/TS: import from the design tokens module
   - Verify the visual output is unchanged (same computed value)

4. VALIDATION REPORT
   ```
   DESIGN SYSTEM VALIDATION REPORT

   Design system: <repo or source name>
   Token count: <N>
   Component count: <M>

   Token drift items: <N found / N fixed>
   Inline reimplementations: <N found / N fixed>
   Components not in design system: <list — these are intentional additions>

   Status: PASS | FAIL (FAIL if unfixed drift items remain)
   ```

   If FAIL: list exactly what remains and why it wasn't auto-fixed (e.g., ambiguous match, multiple candidates in the design system).

============================================================
PHASE 3: ROUND-TRIP PUSH (OPTIONAL)
============================================================

Run only when the user asks to push built output back to Claude Design for visual editing.

1. CONFIRM PUSH IS SAFE
   - Check that Phase 2 passed (no unfixed drift items)
   - Warn if there are uncommitted changes: "Uncommitted changes detected. Push will reflect the current disk state."

2. RUN THE PUSH
   ```
   /design-sync push
   ```
   Expected: Claude Design receives the built components as structured canvas elements (not a screenshot).

3. REPORT PUSH RESULT
   - Confirm which components were pushed
   - Note any components excluded (server components, headless utilities)
   - Provide the Claude Design URL where the canvas is now live

4. ROUND-TRIP WORKFLOW REMINDER
   After the designer edits on the canvas:
   ```
   # Pull the updated design system back into Claude Code
   /design-sync pull

   # Run Phase 2 validation again to catch any new drift
   ```

============================================================
STRICT RULES
============================================================

- Never ask which design system to use — read `components.json` and proceed
- Never generate new base components (Button, Input, Card) if they exist in `components.json` — import them
- Never modify design token values — only replace hardcoded values with token references
- Never push if Phase 2 validation fails — fix drift items first
- If `/design-sync` is not available (older Claude Code version), report: "Claude Code v2.2+ required for /design-sync. Update with: npm install -g @anthropic-ai/claude-code@latest"
- Token drift is a bug, not a style preference — fix it without asking

============================================================
OUTPUT
============================================================

End every run with a three-line summary:

```
DESIGN SYNC COMPLETE

Design system: <source> · <N> tokens · <M> components
Drift fixed: <N token values>, <M inline components> → imports
Status: READY TO BUILD | DRIFT ITEMS REMAIN (see report above)
```

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…