/figma-matcher
Enforces pixel-perfect implementation of Figma designs by exhaustively extracting every visual property from Figma, spinning up Chrome DevTools to measure the current implementation, building a full comparison checklist, and fixing all discrepancies in a single pass. MUST be
$ npx -y skills add Flagrare/agent-skills --skill figma-matcher --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/figma-matcher
Context preview
The summary Claude sees to decide when to auto-load this skill.
Enforces pixel-perfect implementation of Figma designs by exhaustively extracting every visual property from Figma, spinning up Chrome DevTools to measure the current implementation, building a full comparison checklist, and fixing all discrepancies in a single pass. MUST be
SKILL.md
figma-matcher.SKILL.mdname: figma-matcher
description: Enforces pixel-perfect implementation of Figma designs by exhaustively extracting every visual property from Figma, spinning up Chrome DevTools to measure the current implementation, building a full comparison checklist, and fixing all discrepancies in a single pass. MUST be triggered whenever implementing UI from Figma, fixing styling to match Figma, or any time the user says "match Figma", "check against Figma", "compare to design", "the design doesn't match", "colors are wrong", "spacing is off", or references a Figma URL in a styling context. Also trigger when you just finished writing CSS/styling code that was informed by a Figma design. This skill is NON-OPTIONAL when Figma designs are involved in styling work.
Figma Matcher
A rigid, checklist-driven process for verifying that implementation matches Figma designs exactly. No visual impressions. No "close enough." Every property gets extracted, compared numerically, and verified.
Why This Exists
Without this process, you will:
- Pick component variants by name without checking their actual hex values
- Assume "gray" means the same gray
- Skip checking spacing, border-radius, font-weight, opacity
- Iterate 3-5 times with the user correcting you each time
This skill eliminates all of that by forcing exhaustive upfront extraction.
HARD GATE
You are FORBIDDEN from calling `Edit` or `Write` on any `.scss`, `.css`, `.sass`, `.less`, or `.styled.*` file until you have: 1. Completed Steps 1-4 below 2. Output the full comparison table to the user 3. Received acknowledgment or no objection from the user
If you catch yourself about to edit a styling file without having shown the comparison table, STOP. Go back to Step 1.
The Process
You MUST complete every step in order. Do not skip steps. Do not combine steps. Do not start writing CSS until Step 5.
Step 0: Find the Frames and Inventory EVERYTHING In Them
Before extracting anything, locate the exact node ids and enumerate what the design actually contains.
**Finding node ids when you only have a file key or section name:**
- `get_metadata` with no nodeId lists top-level pages; with a page id it should enumerate the tree — but page-level enumeration sometimes returns an empty `width="0"` canvas. Node-level calls still work, so the gap is discovery only.
- When enumeration fails, drive the browser: open the Figma file in the user's Chrome (debug profile), use Figma's **Find** (the search icon in the left sidebar), search the frame/section name, click "See results on other pages" if needed, then click each result and read the `node-id` from the URL. Collect all of them before extracting.
**Coverage rule — account for every child, then decide:** Run `get_metadata` on the section/frame and list EVERY child frame and instance: desktop frame, mobile frames (closed AND open/overlay states), popout menus, dropdowns, sheets, and every instance inside container rows. For each one, explicitly classify it as (a) in scope, (b) already implemented elsewhere (verify — go look), or (c) out of scope per the user. Never dismiss an instance as "page chrome" without checking the page actually renders it in this context — a tabs-row instance can contain a control (e.g. a store-status dropdown) that the current page is missing entirely. A missed instance is a missed feature, not a styling nit.
Interaction states are frames too: a mockup with a cursor on a row is showing you the hover state; a second mobile frame with an overlay is showing you the opened sheet. Both become checklist rows.
Step 1: Extract ALL Properties from Figma — Fetch, Don't Transcribe
Machine-readable extraction first; hand-reading generated output is the biggest error source. In order:
1. **`get_variable_defs`** on the main node — returns the design-token map as JSON (`{"Gray/Gray30": "#E7E7E7", "Spacing/spacing-small": "8", "Regular/Medium": "Font(...16, weight: 500, lineHeight: 24...)"}`). This is ground truth for every tokenized color, spacing, radius, font, and shadow. Save it; Step 2 joins against it. 2. **`get_metadata`** on the frame — exact geometry for free: row heights, column widths, x/y offsets, element sizes. Gaps and paddings fall out of the coordinate math (`y=83, height=56, next y=155` → 16px gap). 3. **`get_design_context`** on SMALL nodes only — one atomic piece at a time (a header cell, a row cell, a button, a menu). Large frames silently degrade to sparse metadata with a note telling you to recurse into sublayers; budget for one call per atomic component. 4. **`get_screenshot`** on every frame (desktop, mobile, open states) — download the PNGs; they are the Step 6 visual baseline. 5. **Optional, most exact: Figma REST API** — `GET https://api.figma.com/v1/files/:key/nodes?ids=:nodeId` with an `X-Figma-Token` PAT returns the raw node JSON: fills/strokes as r/g/b/a **floats 0-1 (multiply by 255)**, `cornerRadius`, auto-layout paddings, `itemSpacing`, text `style`, `effects`. Use when a PAT is available; note the sandbox may need `api.figma.com` allowed. The Variables REST endpoint (`/variables/local`) is Enterprise-only — `get_variable_defs` is the plan-independent substitute.
For each visual element, extract into a structured checklist:
**Colors** (resolve ALL to hex + rgba):
- Background color (including gradients, overlays, composite backgrounds)
- Border color + opacity
- Text color
- Icon color/fill
- Button background (default, hover, active, disabled states)
- Shadow colors
**Typography:**
- Font family
- Font weight (numeric, not name)
- Font size (px)
- Line height (px or unitless)
- Letter spacing
- Text transform
**Spacing:**
- Padding (top, right, bottom, left)
- Margin (top, right, bottom, left)
- Gap between elements
**Layout:**
- Width (fixed, %, auto, fill)
- Height (fixed, auto, fit-content)
- Display (flex, grid, block)
- Flex direction, align-items, justify-content
- Border radius (each corner if different)
**Borders:**
- Bord
Read more
name: figma-matcher description: Enforces pixel-perfect implementation of Figma designs by exhaustively extracting every visual property from Figma, spinning up Chrome DevTools to measure the current implementation, building a full comparison checklist, and fixing all discrepancies in a single pass. MUST be triggered whenever implementing UI from Figma, fixing styling to match Figma, or any time the user says "match Figma", "check against Figma", "compare to design", "the design doesn't match", "colors are wrong", "spacing is off", or references a Figma URL in a styling context. Also trigger when you just finished writing CSS/styling code that was informed by a Figma design. This skill is NON-OPTIONAL when Figma designs are involved in styling work.
Figma Matcher
A rigid, checklist-driven process for verifying that implementation matches Figma designs exactly. No visual impressions. No "close enough." Every property gets extracted, compared numerically, and verified.
Why This Exists
Without this process, you will:
- Pick component variants by name without checking their actual hex values
- Assume "gray" means the same gray
- Skip checking spacing, border-radius, font-weight, opacity
- Iterate 3-5 times with the user correcting you each time
This skill eliminates all of that by forcing exhaustive upfront extraction.
HARD GATE
You are FORBIDDEN from calling `Edit` or `Write` on any `.scss`, `.css`, `.sass`, `.less`, or `.styled.*` file until you have: 1. Completed Steps 1-4 below 2. Output the full comparison table to the user 3. Received acknowledgment or no objection from the user
If you catch yourself about to edit a styling file without having shown the comparison table, STOP. Go back to Step 1.
The Process
You MUST complete every step in order. Do not skip steps. Do not combine steps. Do not start writing CSS until Step 5.
Step 0: Find the Frames and Inventory EVERYTHING In Them
Before extracting anything, locate the exact node ids and enumerate what the design actually contains.
**Finding node ids when you only have a file key or section name:**
- `get_metadata` with no nodeId lists top-level pages; with a page id it should enumerate the tree — but page-level enumeration sometimes returns an empty `width="0"` canvas. Node-level calls still work, so the gap is discovery only.
- When enumeration fails, drive the browser: open the Figma file in the user's Chrome (debug profile), use Figma's **Find** (the search icon in the left sidebar), search the frame/section name, click "See results on other pages" if needed, then click each result and read the `node-id` from the URL. Collect all of them before extracting.
**Coverage rule — account for every child, then decide:** Run `get_metadata` on the section/frame and list EVERY child frame and instance: desktop frame, mobile frames (closed AND open/overlay states), popout menus, dropdowns, sheets, and every instance inside container rows. For each one, explicitly classify it as (a) in scope, (b) already implemented elsewhere (verify — go look), or (c) out of scope per the user. Never dismiss an instance as "page chrome" without checking the page actually renders it in this context — a tabs-row instance can contain a control (e.g. a store-status dropdown) that the current page is missing entirely. A missed instance is a missed feature, not a styling nit.
Interaction states are frames too: a mockup with a cursor on a row is showing you the hover state; a second mobile frame with an overlay is showing you the opened sheet. Both become checklist rows.
Step 1: Extract ALL Properties from Figma — Fetch, Don't Transcribe
Machine-readable extraction first; hand-reading generated output is the biggest error source. In order:
1. **`get_variable_defs`** on the main node — returns the design-token map as JSON (`{"Gray/Gray30": "#E7E7E7", "Spacing/spacing-small": "8", "Regular/Medium": "Font(...16, weight: 500, lineHeight: 24...)"}`). This is ground truth for every tokenized color, spacing, radius, font, and shadow. Save it; Step 2 joins against it. 2. **`get_metadata`** on the frame — exact geometry for free: row heights, column widths, x/y offsets, element sizes. Gaps and paddings fall out of the coordinate math (`y=83, height=56, next y=155` → 16px gap). 3. **`get_design_context`** on SMALL nodes only — one atomic piece at a time (a header cell, a row cell, a button, a menu). Large frames silently degrade to sparse metadata with a note telling you to recurse into sublayers; budget for one call per atomic component. 4. **`get_screenshot`** on every frame (desktop, mobile, open states) — download the PNGs; they are the Step 6 visual baseline. 5. **Optional, most exact: Figma REST API** — `GET https://api.figma.com/v1/files/:key/nodes?ids=:nodeId` with an `X-Figma-Token` PAT returns the raw node JSON: fills/strokes as r/g/b/a **floats 0-1 (multiply by 255)**, `cornerRadius`, auto-layout paddings, `itemSpacing`, text `style`, `effects`. Use when a PAT is available; note the sandbox may need `api.figma.com` allowed. The Variables REST endpoint (`/variables/local`) is Enterprise-only — `get_variable_defs` is the plan-independent substitute.
For each visual element, extract into a structured checklist:
**Colors** (resolve ALL to hex + rgba):
- Background color (including gradients, overlays, composite backgrounds)
- Border color + opacity
- Text color
- Icon color/fill
- Button background (default, hover, active, disabled states)
- Shadow colors
**Typography:**
- Font family
- Font weight (numeric, not name)
- Font size (px)
- Line height (px or unitless)
- Letter spacing
- Text transform
**Spacing:**
- Padding (top, right, bottom, left)
- Margin (top, right, bottom, left)
- Gap between elements
**Layout:**
- Width (fixed, %, auto, fill)
- Height (fixed, auto, fit-content)
- Display (flex, grid, block)
- Flex direction, align-items, justify-content
- Border radius (each corner if different)
**Borders:**
- Bord
Showing the first part of this file.
Thirty-two skills that wrap around your development cycle in Claude Code. They turn tickets into ATDD plans, smoke-test features against a running app or service, hunt down bugs with runtime evidence, guard commits against doc drift, run seven-axis code
Repo: Flagrare/agent-skills
Other skills on flagrare-agent-skills.
- /atdd-plan
Produce an ATDD-first implementation plan in Claude Code's native plan mode, with named design patterns called out where they earn their keep. The skill enters plan mode automatically (via the EnterPlanMode tool), runs /flagrare:codebase-explore to ground the plan in the actual
Open skill - /brag-doc
Generate a comprehensive, impact-framed brag-doc entry for a chosen time window (day, week, biweek, month, or custom). Pulls authored PRs, reviews given, commits, deploys, and linked tickets across GitHub, local git, and configured MCPs, then synthesises a themed narrative,
Open skill - /bug-bash
Programmatic bug bashing, ingest a prescribed test plan (Notion, markdown, pasted spec), drive a real running system (browser via Chrome DevTools / Playwright MCP, backend via API tools when relevant), run every prescribed case with evidence, then do exploratory passes
Open skill - /codebase-explore
Explore the codebase to map conventions, reusable utilities, analogous features, and data flows relevant to a planned change. Returns raw findings (file paths, patterns, code snippets), does NOT produce a plan. Used by /flagrare:atdd-plan as its codebase understanding step.
Open skill - /daily-code-review
Generate a daily code review report showing stale PRs, items needing your attention, and active work for your team. Use whenever the user asks for a PR report, code review status, daily standup prep, team PR overview, "what needs review", "what's stale", "show me open PRs",
Open skill - /debug-hunt
Evidence-first debugging for bugs that are hard to reproduce, intermittent, performance-related, or where previous static-analysis fixes have failed. Declares an explicit goal via /goal (the bug no longer reproduces), then loops through Hypothesis → Instrument → Reproduce →
Open skill

