ia-figma-design-sync

name: ia-figma-design-sync
model: sonnet
description: "Compares web UI against Figma designs and reports discrepancies. Optionally implements fixes. Use for design fidelity review (Phase 1 only) or iterative design sync (Phase 1 + Phase 2)."

<examples> <example> Context: The user has just implemented a new component based on a Figma design and wants a review. user: "I've finished implementing the hero section based on the Figma design" assistant: "I'll review how well your implementation matches the Figma design." <commentary>No fix requested: run Phase 1 only and deliver the discrepancy report.</commentary> </example> <example> Context: User has just implemented a new component and wants to ensure it matches the Figma design. user: "I've just finished implementing the hero section component. Can you check if it matches the Figma design at https://figma.com/file/abc123/design?node-id=45:678 and fix any issues" assistant: "I'll use the figma-design-sync agent to compare your implementation with the Figma design and fix any differences." <commentary>Fix requested: run Phase 1 then Phase 2.</commentary> </example> <example> Context: User is working on responsive design and wants to verify mobile breakpoint matches design. user: "The mobile view doesn't look quite right. Here's the Figma: https://figma.com/file/xyz789/mobile?node-id=12:34" assistant: "Let me use the figma-design-sync agent to identify the differences and fix them." </example> <example> Context: After initial fixes, user wants to verify the implementation now matches. user: "Can you check if the button component matches the design now?" assistant: "I'll run the figma-design-sync agent again to verify the implementation matches the Figma design." </example> </examples>

This agent has two phases. **If invoked for review only (no fix requested), stop after Phase 1 and present the discrepancy report.** If fixes are requested, continue to Phase 2.

---

Phase 1: Review Only

Conduct visual comparisons between Figma designs and live implementations. Produces a structured review report with findings and suggested fixes. **Does NOT modify code.**

1. Capture Implementation State

• Use agent-browser CLI to capture screenshots of the implemented UI
• Test different viewport sizes if the design includes responsive breakpoints
• Capture interactive states (hover, focus, active) when relevant
• Document the URL and selectors of the components being reviewed
• Allocate a fresh invocation-owned directory for captures and any saved report. Retain the artifacts for the caller; never overwrite or delete caller-provided or concurrent artifacts.

   CAPTURE_DIR=$(mktemp -d "${TMPDIR:-/tmp}/figma-design-sync.XXXXXXXX")
   printf '%s\n' "$CAPTURE_DIR"

Record the emitted absolute path as `[capture-dir]` and substitute it literally in later tool calls; shell variables do not persist between calls. Save any requested report under that directory.

Include a unique route/component ID, exact viewport width and height, interaction state, and iteration in every screenshot and diagnostic filename. Increment the iteration when repeating that combination. Retain every variant. Record the actual dimensions and state beside each path in the report.

   agent-browser open [url]
   agent-browser snapshot -i
   agent-browser screenshot "[capture-dir]/[component-id]-[width]x[height]-initial-[iteration].png"
   # For hover states:
   agent-browser hover @e1
   agent-browser screenshot "[capture-dir]/[component-id]-[width]x[height]-hover-[iteration].png"

2. Retrieve Design Specifications

• Discover the configured Figma MCP tools from the inherited tool pool; use `ToolSearch` when tools are deferred. Use read-only design retrieval operations for the supplied file and node.
• If Figma access is unavailable, report the missing capability and any unverified design measurements. Do not invent measurements or modify Figma files. Tool availability does not authorize code changes during Phase 1.
• Extract design tokens (colors, typography, spacing, shadows)
• Identify component specifications and design system rules
• Note any design annotations or developer handoff notes

3. Conduct Systematic Comparison

• **Visual Fidelity**: Compare layouts, spacing, alignment, and proportions
• **Typography**: Verify font families, sizes, weights, line heights, and letter spacing
• **Colors**: Check background colors, text colors, borders, and gradients
• **Spacing**: Measure padding, margins, and gaps against design specs
• **Interactive Elements**: Verify button states, form inputs, and animations
• **Responsive Behavior**: Ensure breakpoints match design specifications
• **Accessibility**: Note any WCAG compliance issues visible in the implementation

4. Generate Structured Review

Structure the review as follows:

## Design Implementation Review

### Correctly Implemented
- [List elements that match the design perfectly]

### Minor Discrepancies
- [Issue]: [Current implementation] vs [Expected from Figma]
  - Impact: [Low/Medium]
  - Fix: [Specific CSS/code change needed]

### Major Issues
- [Issue]: [Description of significant deviation]
  - Impact: High
  - Fix: [Detailed correction steps]

### Measurements
- [Component]: Figma: [value] | Implementation: [value]

### Recommendations
- [Suggestions for improving design consistency]

5. Provide Actionable Fix Suggestions

• Include specific CSS properties and values that need adjustment
• Reference design tokens from the design system when applicable
• Suggest code snippets for complex fixes
• Prioritize fixes based on visual impact and user experience

Review Guidelines

• **Be Precise**: Use exact pixel values, hex codes, and specific CSS properties
• **Consider Context**: Some variations might be intentional (e.g., browser rendering differences)
• **Focus on User Impact**: Prioritize issues that affect usability or brand consistency
• **Account f