Skip to main content
Catch design drift before it ships. This automation runs on every PR with UI changes — it takes screenshots of the updated components, pulls the corresponding Figma frames via the Figma MCP, and posts an inline review on the PR with specific callouts for spacing, color, typography, and layout deltas.

Use this template

Open Figma Design Review on PR in Devin and create the automation with the default configuration. You can customize it before saving.
Looking for a hands-on walkthrough? See the step-by-step tutorial for Figma Design Review on PR.

​
What this automation does

Design review is one of the hardest parts of frontend engineering to automate. The Figma MCP gives Devin programmatic access to the source-of-truth designs — tokens, component specs, frame dimensions — so it can compare a rendered component against what the designer actually specified and give precise feedback on divergence.

​
How it works

Trigger: Github event — pull.request
  • Event: github:pull_request
    • Conditions:
      • action eq opened
      • repository.full_name eq your-org/your-repo
What Devin does: Starts a session with full event context, executes the prompt below, and (optionally) notifies you on failure.

​
Prerequisites

​
Example prompt

The template ships with this prompt. You can edit it after clicking Use template, or leave it as-is.

​
Setting it up

  1. Open Automations → Templates in Devin.
  2. Click Figma Design Review on PR. The create page opens with this template pre-filled.
  3. Connect any required integrations and install MCP servers if you haven’t already.
  4. Replace any placeholder values in the trigger conditions (for example, swap your-org/your-repo for your actual repo).
  5. Review the prompt and adjust it for your team’s language, conventions, and guardrails.
  6. Click Create automation.
Most automation templates include suggested ACU and invocation limits to bound cost during early rollout. Keep them as-is until you’re confident in the automation’s behavior, then raise them to fit your workload.

​
When to use this template

  • Design-system-heavy teams where visual fidelity matters
  • Large frontend codebases with many contributors of varying design sensibility
  • Reducing design-review bottlenecks (instead of waiting for a designer to review every PR)
  • Enforcing visual consistency across a product

​
Customization ideas

  • Scope to specific repos, directories, or file patterns
  • Configure design-token tolerances (pixel-perfect vs. “close enough”)
  • Add a required Figma file ID to each PR template
  • Chain with a design-system lint rule to block merges on major drift

​
See also