picasso-skill 2.1.2 → 2.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/agents/picasso.md +172 -62
- package/commands/figma.md +97 -0
- package/commands/godmode.md +14 -2
- package/commands/mood.md +44 -10
- package/commands/preset.md +40 -10
- package/commands/preview.md +52 -0
- package/commands/roast.md +22 -7
- package/commands/score.md +21 -3
- package/commands/steal.md +37 -6
- package/commands/variants.md +31 -12
- package/package.json +1 -1
- package/references/figma-mcp.md +190 -0
- package/references/visual-preview.md +359 -0
package/commands/roast.md
CHANGED
|
@@ -2,20 +2,35 @@ Run the Picasso /roast command -- brutally honest design critique.
|
|
|
2
2
|
|
|
3
3
|
Use the Picasso agent to review the current project's frontend with sharp, designer-Twitter energy.
|
|
4
4
|
|
|
5
|
-
MANDATORY FIRST STEP --
|
|
5
|
+
MANDATORY FIRST STEP -- Gather visual evidence before writing anything:
|
|
6
|
+
|
|
7
|
+
**Option A: Live site (localhost or URL)**
|
|
6
8
|
1. Take screenshots: `npx playwright screenshot http://localhost:PORT /tmp/picasso-roast-desktop.png --viewport-size=1440,900` (and mobile at 375,812)
|
|
7
9
|
2. Use the Read tool to VIEW the screenshot files: `Read /tmp/picasso-roast-desktop.png` and `Read /tmp/picasso-roast-mobile.png`
|
|
8
10
|
3. Base ALL visual observations on what you actually see in the screenshots, NOT on code/CSS classes
|
|
9
|
-
|
|
11
|
+
|
|
12
|
+
**Option B: Figma file (URL provided or MCP available)**
|
|
13
|
+
1. Extract file_key from the Figma URL
|
|
14
|
+
2. Fetch the target frame via `mcp__figma__get_node` for structural data (spacing, colors, typography, auto-layout)
|
|
15
|
+
3. Export the frame as an image via `mcp__figma__get_image` for visual review
|
|
16
|
+
4. Fetch styles via `mcp__figma__get_styles` to check design system usage
|
|
17
|
+
5. Base structural observations on MCP data (exact values) and visual observations on the exported image
|
|
18
|
+
|
|
19
|
+
**Option C: Both exist (Figma + live site)**
|
|
20
|
+
1. Do both A and B
|
|
21
|
+
2. Include a "Design vs Implementation" delta section in the roast — flag where the dev diverged from the design
|
|
22
|
+
|
|
23
|
+
4. If NEITHER screenshots NOR Figma MCP work, tell the user and DO NOT make visual claims. You can still audit code patterns but must prefix findings with "Based on code analysis only (no screenshot):"
|
|
10
24
|
|
|
11
25
|
ANTI-HALLUCINATION RULES:
|
|
12
|
-
- NEVER say "this is light mode" or "dark mode" without viewing a screenshot
|
|
26
|
+
- NEVER say "this is light mode" or "dark mode" without viewing a screenshot or Figma frame data
|
|
13
27
|
- NEVER describe colors, layouts, or visual appearance from code alone
|
|
14
|
-
- NEVER claim "this looks like X" without a screenshot to verify
|
|
15
|
-
- Code classes (e.g. `dark:bg-gray-900`) tell you what COULD render; only screenshots show what DOES render
|
|
28
|
+
- NEVER claim "this looks like X" without a screenshot or Figma export to verify
|
|
29
|
+
- Code classes (e.g. `dark:bg-gray-900`) tell you what COULD render; only screenshots/Figma show what DOES render
|
|
30
|
+
- When using Figma MCP data, you CAN state exact values (e.g., "spacing is 17px" or "fill is #808080") because these are structural facts, not visual guesses
|
|
16
31
|
|
|
17
32
|
Rules:
|
|
18
|
-
- Be specific about every criticism (file:line or
|
|
33
|
+
- Be specific about every criticism (file:line, element reference, or Figma node name)
|
|
19
34
|
- Be funny and cutting, but never mean about the developer -- only the design
|
|
20
35
|
- Every roast point MUST include the fix
|
|
21
36
|
- End with a genuine compliment about what IS working
|
|
@@ -26,7 +41,7 @@ Format:
|
|
|
26
41
|
```
|
|
27
42
|
🔥🔥🔥 ROAST SCORE: X/5
|
|
28
43
|
|
|
29
|
-
[Sharp, specific critiques with file:line references -- all visual claims backed by screenshot]
|
|
44
|
+
[Sharp, specific critiques with file:line references or Figma node names -- all visual claims backed by screenshot or MCP data]
|
|
30
45
|
|
|
31
46
|
Here's how to fix it:
|
|
32
47
|
1. [Fix with exact code/instruction]
|
package/commands/score.md
CHANGED
|
@@ -2,15 +2,29 @@ Run the Picasso /score command -- quantified design quality score.
|
|
|
2
2
|
|
|
3
3
|
Use the Picasso agent to score the current project's frontend design on a 0-100 scale.
|
|
4
4
|
|
|
5
|
-
MANDATORY FIRST STEP --
|
|
5
|
+
MANDATORY FIRST STEP -- Gather visual evidence before scoring:
|
|
6
|
+
|
|
7
|
+
**Option A: Live site (localhost or URL)**
|
|
6
8
|
1. Take screenshots: `npx playwright screenshot http://localhost:PORT /tmp/picasso-score-desktop.png --viewport-size=1440,900` (and mobile at 375,812)
|
|
7
9
|
2. Use the Read tool to VIEW the screenshot files before scoring visual categories
|
|
8
10
|
3. If screenshots fail, tell the user and score only code-auditable categories (mark visual categories as "N/A - no screenshot")
|
|
9
11
|
|
|
12
|
+
**Option B: Figma file (URL provided or MCP available)**
|
|
13
|
+
1. Fetch the target frame via `mcp__figma__get_node` for structural data
|
|
14
|
+
2. Fetch styles via `mcp__figma__get_styles` for design system analysis
|
|
15
|
+
3. Export frame as image via `mcp__figma__get_image` for visual review
|
|
16
|
+
4. Score based on both structural data (exact values) and exported image
|
|
17
|
+
5. Add bonus category: Design System Health (0-10)
|
|
18
|
+
|
|
19
|
+
**Option C: Both (Figma + live site)**
|
|
20
|
+
1. Do both A and B
|
|
21
|
+
2. Add category: Design Fidelity (0-10) -- how closely implementation matches Figma intent
|
|
22
|
+
|
|
10
23
|
ANTI-HALLUCINATION RULES:
|
|
11
|
-
- Visual categories (Typography appearance, Color in practice, Spacing rhythm, Anti-Slop visual check) MUST be scored from screenshots, not code alone
|
|
24
|
+
- Visual categories (Typography appearance, Color in practice, Spacing rhythm, Anti-Slop visual check) MUST be scored from screenshots or Figma exports, not code alone
|
|
12
25
|
- Code-auditable categories (a11y violations via axe, transition:all grep, prefers-reduced-motion grep) can be scored from code
|
|
13
|
-
-
|
|
26
|
+
- When using Figma MCP, structural data (exact spacing, color, typography values) IS factual and can be stated directly
|
|
27
|
+
- Never claim "this looks like X" without viewing a screenshot or Figma export
|
|
14
28
|
|
|
15
29
|
Categories:
|
|
16
30
|
- Typography (0-15): font choice, type scale, max-width, line-height, letter-spacing
|
|
@@ -22,4 +36,8 @@ Categories:
|
|
|
22
36
|
- Performance (0-10): Lighthouse perf score mapped 0-100 -> 0-10
|
|
23
37
|
- Anti-Slop (0-10): deductions for each AI-slop fingerprint detected (-2 each)
|
|
24
38
|
|
|
39
|
+
Bonus categories (when Figma MCP is available):
|
|
40
|
+
- Design System Health (0-10): style usage %, component coverage, naming consistency, auto-layout adoption
|
|
41
|
+
- Design Fidelity (0-10, only when both Figma + live): token match, spacing accuracy, structural parity
|
|
42
|
+
|
|
25
43
|
Output format with visual bars and top fixes for maximum point improvement.
|
package/commands/steal.md
CHANGED
|
@@ -1,12 +1,43 @@
|
|
|
1
|
-
Run the Picasso /steal command -- extract design DNA from a URL.
|
|
1
|
+
Run the Picasso /steal command -- extract design DNA from a URL or Figma file.
|
|
2
2
|
|
|
3
|
-
Use the Picasso agent to extract the design language from the provided
|
|
3
|
+
Use the Picasso agent to extract the design language from the provided source: $ARGUMENTS
|
|
4
|
+
|
|
5
|
+
## Input Detection
|
|
6
|
+
|
|
7
|
+
- **Figma URL** (contains `figma.com/design/` or `figma.com/file/`): Use Figma MCP for precise extraction
|
|
8
|
+
- **Live URL** (any other http/https): Use Playwright screenshots + source scraping
|
|
9
|
+
- **Both provided**: Use both sources, Figma as ground truth and live site for verification
|
|
10
|
+
|
|
11
|
+
## Steps: Figma URL (Preferred)
|
|
12
|
+
|
|
13
|
+
1. Extract `file_key` and optional `node_id` from the Figma URL
|
|
14
|
+
2. Fetch styles via `mcp__figma__get_styles` — extract all color styles, text styles, effect styles
|
|
15
|
+
3. Fetch target frame via `mcp__figma__get_node` — extract auto-layout spacing, fills, strokes, radii
|
|
16
|
+
4. Fetch components via `mcp__figma__get_components` — understand component structure
|
|
17
|
+
5. Export frame as image via `mcp__figma__get_image` for visual reference
|
|
18
|
+
6. Analyze the extracted data:
|
|
19
|
+
- **Colors:** All fill/stroke colors → convert to OKLCH. Identify primary, secondary, accent, neutral.
|
|
20
|
+
- **Typography:** Font families, size scale, weight distribution, line-height ratios.
|
|
21
|
+
- **Spacing:** Auto-layout itemSpacing and padding → detect base unit (4px? 8px?) and scale.
|
|
22
|
+
- **Shadows:** Effect styles → map to elevation scale.
|
|
23
|
+
- **Radii:** Border radius values → detect pattern (uniform? progressive?).
|
|
24
|
+
- **Layout:** Auto-layout direction, alignment, wrapping → grid/flex patterns.
|
|
25
|
+
7. Generate a `.picasso.md` config matching the extracted aesthetic
|
|
26
|
+
8. Optionally generate a `DESIGN.md` with the full token set
|
|
27
|
+
|
|
28
|
+
## Steps: Live URL
|
|
4
29
|
|
|
5
|
-
Steps:
|
|
6
30
|
1. Screenshot the URL at desktop (1440x900) and mobile (375x812)
|
|
7
31
|
2. Fetch the page source and extract: font-family declarations, color values (#hex, rgb, oklch), border-radius values, box-shadow values
|
|
8
32
|
3. Analyze the screenshots visually for: layout structure, spacing rhythm, typography hierarchy, color palette, animation style
|
|
9
|
-
4. Generate a
|
|
10
|
-
5. Optionally generate a DESIGN.md with the full token set
|
|
33
|
+
4. Generate a `.picasso.md` config that matches the extracted aesthetic
|
|
34
|
+
5. Optionally generate a `DESIGN.md` with the full token set
|
|
35
|
+
|
|
36
|
+
## Steps: Both (Figma + Live URL)
|
|
37
|
+
|
|
38
|
+
1. Run Figma extraction (ground truth for intended design)
|
|
39
|
+
2. Run live URL extraction (what actually shipped)
|
|
40
|
+
3. Generate tokens from Figma source
|
|
41
|
+
4. Note any divergences between design and implementation in the output
|
|
11
42
|
|
|
12
|
-
If no URL is provided, ask the user for one.
|
|
43
|
+
If no URL is provided, ask the user for one. Accept both Figma URLs and live URLs.
|
package/commands/variants.md
CHANGED
|
@@ -1,18 +1,37 @@
|
|
|
1
|
-
|
|
1
|
+
---
|
|
2
|
+
name: variants
|
|
3
|
+
description: "Generate 2-3 distinct visual directions with side-by-side visual previews for A/B comparison."
|
|
4
|
+
---
|
|
2
5
|
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
6
|
+
# /variants -- Visual Direction Comparison
|
|
7
|
+
|
|
8
|
+
Generate 2-3 genuinely different aesthetic directions and show them as a side-by-side visual preview.
|
|
9
|
+
|
|
10
|
+
## Steps
|
|
11
|
+
|
|
12
|
+
1. Read the current project's design context (`.picasso.md`, `DESIGN.md`, or infer from code)
|
|
13
|
+
2. Study the project type, audience, and competitive landscape to inform direction choices
|
|
14
|
+
3. Generate 2-3 genuinely different aesthetic directions. NOT slight variations -- each must differ in at least 3 of: font, color palette, layout structure, border-radius philosophy, motion intensity
|
|
15
|
+
4. For each direction:
|
|
7
16
|
- Name it (e.g., "Editorial Minimalist", "Dark Terminal", "Warm Organic")
|
|
8
|
-
- List the 5 key design tokens (font, accent color, radius, shadow style
|
|
9
|
-
- Describe what makes it distinctive in 1
|
|
10
|
-
|
|
11
|
-
|
|
12
|
-
|
|
17
|
+
- List the 5 key design tokens (heading font, body font, accent color, radius, shadow style)
|
|
18
|
+
- Describe what makes it distinctive in 1 sentence
|
|
19
|
+
5. **Generate a visual preview (MANDATORY):**
|
|
20
|
+
- Load `references/visual-preview.md` and use the Side-by-Side Direction Comparison template
|
|
21
|
+
- For each direction, render a preview card showing: color palette strip, nav bar, heading, body text, sample card, primary/secondary buttons, input field -- all in that direction's tokens
|
|
22
|
+
- Load fonts using the Font Mapping table from `references/visual-preview.md`
|
|
23
|
+
- Write the comparison HTML to `/tmp/picasso-variants.html`
|
|
24
|
+
- Open via Playwright MCP: `mcp__playwright__browser_navigate` to `file:///tmp/picasso-variants.html`
|
|
25
|
+
- Screenshot at 1440x900 viewport
|
|
26
|
+
- View the screenshot with the Read tool
|
|
27
|
+
6. Present the visual comparison to the user: "Here are the directions. Which speaks to you? Pick one, combine elements, or reject all."
|
|
28
|
+
7. Also tell the user: "Open `/tmp/picasso-variants.html` in your browser for full resolution."
|
|
29
|
+
|
|
30
|
+
## Rules
|
|
13
31
|
|
|
14
|
-
Rules:
|
|
15
32
|
- Each direction must pass the 3-second anti-slop test independently
|
|
16
|
-
- No two directions can share the same font
|
|
33
|
+
- No two directions can share the same heading font
|
|
17
34
|
- At least one direction must be surprising or unconventional
|
|
18
35
|
- Always include one "safe" option and one "bold" option
|
|
36
|
+
- Visual preview is MANDATORY, not optional. If Playwright MCP is unavailable, write the HTML file and tell the user the path to open manually.
|
|
37
|
+
- Never describe what the directions look like without viewing the screenshot first
|
package/package.json
CHANGED
|
@@ -0,0 +1,190 @@
|
|
|
1
|
+
# Figma MCP Integration
|
|
2
|
+
|
|
3
|
+
Reference for using Figma's Model Context Protocol (MCP) server to access design data directly from Figma files. This replaces or supplements Playwright screenshots with structured design information.
|
|
4
|
+
|
|
5
|
+
## Why Figma MCP > Screenshots
|
|
6
|
+
|
|
7
|
+
Screenshots show pixels. Figma MCP gives you the **design graph**: layers, tokens, spacing values, component instances, styles, and constraints. This means:
|
|
8
|
+
|
|
9
|
+
- **Accurate color extraction:** Get exact hex/OKLCH values, not color-picked approximations
|
|
10
|
+
- **Real spacing values:** Read auto-layout gaps, padding, and margins as the designer set them
|
|
11
|
+
- **Typography facts:** Font family, weight, size, line-height, letter-spacing — all exact
|
|
12
|
+
- **Component structure:** See which components are instances, variants, and overrides
|
|
13
|
+
- **Design intent:** Understand constraints, auto-layout direction, and responsive behavior
|
|
14
|
+
|
|
15
|
+
## When to Use Figma MCP vs Playwright
|
|
16
|
+
|
|
17
|
+
| Scenario | Use Figma MCP | Use Playwright |
|
|
18
|
+
|---|---|---|
|
|
19
|
+
| Auditing a Figma design before implementation | ✅ | ❌ |
|
|
20
|
+
| Extracting design tokens from a Figma file | ✅ | ❌ |
|
|
21
|
+
| Reviewing a live deployed site | ❌ | ✅ |
|
|
22
|
+
| Comparing Figma design vs live implementation | ✅ + ✅ | ✅ only |
|
|
23
|
+
| Generating a DESIGN.md from existing design | ✅ preferred | ✅ fallback |
|
|
24
|
+
| Roasting a design that only exists in Figma | ✅ | ❌ |
|
|
25
|
+
|
|
26
|
+
**Rule:** If the user provides a Figma URL or mentions a Figma file, always prefer Figma MCP. If they provide a live URL or localhost, use Playwright. If both exist, use both for comparison.
|
|
27
|
+
|
|
28
|
+
## MCP Server Options
|
|
29
|
+
|
|
30
|
+
Two main Figma MCP implementations:
|
|
31
|
+
|
|
32
|
+
### Option A: Figma's Official MCP (REST API)
|
|
33
|
+
Package: `@anthropic/figma-mcp` or Figma's official MCP server
|
|
34
|
+
- Uses Figma REST API with a personal access token
|
|
35
|
+
- Read-only: fetch files, nodes, styles, components, export images
|
|
36
|
+
- Best for: CI/CD, automated audits, headless analysis
|
|
37
|
+
- Tools: `get_file`, `get_node`, `get_styles`, `get_components`, `get_image`
|
|
38
|
+
|
|
39
|
+
### Option B: Talk to Figma MCP (Live Connection)
|
|
40
|
+
Package: `cursor-talk-to-figma-mcp` (localhost:3055)
|
|
41
|
+
- Connects to a running Figma instance via plugin
|
|
42
|
+
- **Read AND write**: read frames, update text/properties, create shapes, adjust spacing
|
|
43
|
+
- Best for: interactive design work, syncing copy, wireframing
|
|
44
|
+
- Can snapshot frames and verify changes visually
|
|
45
|
+
|
|
46
|
+
**Which to use:**
|
|
47
|
+
- For Picasso audits/roasts/scoring → Either works. REST API is simpler.
|
|
48
|
+
- For `/steal` token extraction → REST API preferred (structured data).
|
|
49
|
+
- For `/figma --compare` → REST API for Figma data + Playwright for live site.
|
|
50
|
+
- For interactive design updates (changing copy, adjusting spacing) → Talk to Figma MCP.
|
|
51
|
+
|
|
52
|
+
## Available MCP Tools (REST API)
|
|
53
|
+
|
|
54
|
+
### `mcp__figma__get_file`
|
|
55
|
+
Fetch the full structure of a Figma file.
|
|
56
|
+
- Input: `file_key` (extracted from Figma URL)
|
|
57
|
+
- Returns: Document tree with pages, frames, components, styles
|
|
58
|
+
- Use for: Understanding overall file structure, finding specific frames
|
|
59
|
+
|
|
60
|
+
### `mcp__figma__get_node`
|
|
61
|
+
Fetch a specific node (frame, component, group) by ID.
|
|
62
|
+
- Input: `file_key`, `node_id`
|
|
63
|
+
- Returns: Full node properties including fills, strokes, effects, layout, children
|
|
64
|
+
- Use for: Deep-diving into specific components or sections
|
|
65
|
+
|
|
66
|
+
### `mcp__figma__get_styles`
|
|
67
|
+
Fetch all published styles from the file.
|
|
68
|
+
- Input: `file_key`
|
|
69
|
+
- Returns: Color styles, text styles, effect styles, grid styles
|
|
70
|
+
- Use for: Extracting the design system / token set
|
|
71
|
+
|
|
72
|
+
### `mcp__figma__get_components`
|
|
73
|
+
Fetch all components and component sets.
|
|
74
|
+
- Input: `file_key`
|
|
75
|
+
- Returns: Component names, descriptions, variant properties
|
|
76
|
+
- Use for: Understanding the component library structure
|
|
77
|
+
|
|
78
|
+
### `mcp__figma__get_image`
|
|
79
|
+
Export a node as a rendered image (PNG/SVG/PDF).
|
|
80
|
+
- Input: `file_key`, `node_id`, `format`, `scale`
|
|
81
|
+
- Returns: Image URL
|
|
82
|
+
- Use for: Visual verification when you need to see rendered output alongside data
|
|
83
|
+
|
|
84
|
+
## Available MCP Tools (Talk to Figma — Live Connection)
|
|
85
|
+
|
|
86
|
+
When using the Talk to Figma plugin (localhost:3055), additional capabilities:
|
|
87
|
+
|
|
88
|
+
- **Read frames**: List pages, get frame contents, read text layers
|
|
89
|
+
- **Update text**: Change text content in any text layer
|
|
90
|
+
- **Update properties**: Modify fills, strokes, effects, spacing
|
|
91
|
+
- **Create shapes**: Add rectangles, frames, text nodes
|
|
92
|
+
- **Adjust spacing**: Modify auto-layout padding and gaps
|
|
93
|
+
- **Snapshot**: Export current frame state for visual verification
|
|
94
|
+
|
|
95
|
+
**Critical rule:** After any Figma write operation, snapshot the frame and verify it looks correct before proceeding. Figma changes are live — there's no undo via MCP.
|
|
96
|
+
|
|
97
|
+
## Extracting a Figma File Key
|
|
98
|
+
|
|
99
|
+
From a Figma URL:
|
|
100
|
+
```
|
|
101
|
+
https://www.figma.com/design/ABC123xyz/My-Design-File?node-id=0-1
|
|
102
|
+
^^^^^^^^^
|
|
103
|
+
file_key = ABC123xyz
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
From a Figma node URL:
|
|
107
|
+
```
|
|
108
|
+
https://www.figma.com/design/ABC123xyz/My-Design-File?node-id=123-456
|
|
109
|
+
^^^^^^^^^ ^^^^^^^
|
|
110
|
+
file_key node_id (use 123:456 in API)
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
**Note:** URL uses `-` separator in node-id, but the API expects `:` separator. Convert `123-456` → `123:456`.
|
|
114
|
+
|
|
115
|
+
## Design Token Extraction Workflow
|
|
116
|
+
|
|
117
|
+
When extracting design tokens from Figma for DESIGN.md generation:
|
|
118
|
+
|
|
119
|
+
1. **Get styles** via `get_styles` — these are the designer's intended token set
|
|
120
|
+
2. **Get the root frame** via `get_node` — check auto-layout settings for spacing rhythm
|
|
121
|
+
3. **Map to Picasso tokens:**
|
|
122
|
+
- Color styles → `--color-*` tokens (convert to OKLCH)
|
|
123
|
+
- Text styles → typography scale (check for consistent ratio)
|
|
124
|
+
- Effect styles → shadow scale, blur values
|
|
125
|
+
- Grid styles → layout columns, gutter, margin
|
|
126
|
+
|
|
127
|
+
### Spacing Extraction
|
|
128
|
+
Read auto-layout `itemSpacing` and `paddingTop/Right/Bottom/Left` from frames. Look for patterns:
|
|
129
|
+
- If spacing values are multiples of 4 or 8 → 4px or 8px base unit
|
|
130
|
+
- If spacing values follow a ratio → extract the scale
|
|
131
|
+
|
|
132
|
+
### Color Extraction
|
|
133
|
+
Figma stores colors as RGBA (0-1 float). Convert to OKLCH for Picasso:
|
|
134
|
+
- Extract fills from color styles
|
|
135
|
+
- Group into: primary, secondary, accent, neutral, semantic (success/warning/error)
|
|
136
|
+
- Check that neutrals are tinted (not pure gray) — flag if they aren't
|
|
137
|
+
|
|
138
|
+
### Typography Extraction
|
|
139
|
+
From text styles, extract:
|
|
140
|
+
- Font family (flag if it's Inter/Roboto/system default — suggest alternatives)
|
|
141
|
+
- Size scale (check for consistent modular ratio)
|
|
142
|
+
- Weight usage (should have clear hierarchy: regular body, medium labels, semibold headings)
|
|
143
|
+
- Line-height (check it's proportional, not fixed px for all sizes)
|
|
144
|
+
|
|
145
|
+
## Anti-Patterns to Flag
|
|
146
|
+
|
|
147
|
+
When analyzing Figma files, watch for these common design issues:
|
|
148
|
+
|
|
149
|
+
1. **Detached instances** — Components used but detached from the library. Design debt.
|
|
150
|
+
2. **Inconsistent spacing** — Auto-layout frames with ad-hoc spacing values (17px, 23px, 31px instead of a rhythm).
|
|
151
|
+
3. **Unnamed layers** — "Frame 247", "Group 13". Signals hasty work.
|
|
152
|
+
4. **Color styles not used** — Hardcoded colors instead of style references.
|
|
153
|
+
5. **Text styles not used** — Hardcoded typography instead of style references.
|
|
154
|
+
6. **Missing auto-layout** — Frames positioned absolutely instead of using auto-layout. Breaks responsive behavior.
|
|
155
|
+
7. **Single-variant components** — Components that should have variants but don't (e.g., a button with only one state).
|
|
156
|
+
8. **Enormous frame nesting** — 10+ levels deep. Simplify.
|
|
157
|
+
|
|
158
|
+
## Copy Sync Workflow
|
|
159
|
+
|
|
160
|
+
When working with both Figma designs and code, copy (text content) is a common source of drift. Use Figma MCP to keep them synchronized:
|
|
161
|
+
|
|
162
|
+
1. **Read current copy from Figma** — extract all text layers from target frames
|
|
163
|
+
2. **Compare against code** — diff the Figma text against what's rendered in the implementation
|
|
164
|
+
3. **Determine source of truth** — typically Figma is upstream (design → code), but if copy was updated in code first, flag it
|
|
165
|
+
4. **Sync direction:**
|
|
166
|
+
- Figma newer → update code to match
|
|
167
|
+
- Code newer → flag for designer review (don't auto-write to Figma without confirmation)
|
|
168
|
+
5. **Verify** — after syncing, screenshot the live site and compare against Figma export
|
|
169
|
+
|
|
170
|
+
This is especially useful for:
|
|
171
|
+
- Marketing pages where copy changes frequently
|
|
172
|
+
- Multi-language sites where translations update in Figma
|
|
173
|
+
- Design handoff where developers may use placeholder text
|
|
174
|
+
|
|
175
|
+
## Comparison Workflow: Figma vs Implementation
|
|
176
|
+
|
|
177
|
+
When both a Figma file and live implementation exist:
|
|
178
|
+
|
|
179
|
+
1. Extract tokens from Figma via MCP
|
|
180
|
+
2. Screenshot the live site via Playwright
|
|
181
|
+
3. Compare:
|
|
182
|
+
- Are the Figma fonts actually loaded on the site?
|
|
183
|
+
- Do spacing values match? (Common drift: Figma says 24px, CSS says 1.5rem which computes to 24px — match. Or CSS says `gap-6` which is 24px — match.)
|
|
184
|
+
- Are colors within ΔE < 3 tolerance? (Figma RGBA → site computed OKLCH)
|
|
185
|
+
- Are components structurally similar or did the dev reinterpret the design?
|
|
186
|
+
4. Report discrepancies with severity:
|
|
187
|
+
- **Critical:** Wrong font, wrong primary color, missing sections
|
|
188
|
+
- **High:** Spacing off by >8px, wrong font weights, missing states
|
|
189
|
+
- **Medium:** Minor color drift, slightly different border radius, extra whitespace
|
|
190
|
+
- **Low:** Subpixel differences, minor animation timing differences
|