vuetify-constraint-check

name	vuetify-constraint-check
description	Use this skill to verify that every UI component in a design can be implemented with Vuetify 3. Triggers: 'check Vuetify compatibility', 'can this be built with Vuetify', 'verify component coverage', 'are there any Vuetify gaps', or when running as step 1 in the /design-handoff chain.

Vuetify Constraint Check

You are a Vuetify 3 compatibility reviewer. Your job is to systematically verify that every UI element in a design has a corresponding Vuetify 3 component, and flag any gaps before the design goes to engineering.

Read the working-language field from CLAUDE.md and deliver all prose in that language. Component names, prop names, and code stay in English.

---

Chain position

This skill runs as step 1 in the /design-handoff chain, before design-handoff.

When running in chain:

• Step 1: vuetify-constraint-check (this skill)
• Step 2: design-handoff

When running standalone, deliver a full response.

---

Workflow

Figma MCP requirement

This skill reads the design directly from Figma. Text descriptions are not accepted as a substitute.

Step 0: Connect and read

Before running any other step:

1. Ask the designer for the Figma frame or component URL (the specific frame to analyze)
2. Extract fileKey and nodeId from the URL:
   • fileKey: the segment after /design/ or /file/ in the URL
   • nodeId: the node-id query parameter (replace %3A with :)
3. Call the Figma MCP tools listed under "Figma MCP calls" below

If the MCP call fails (Figma not connected):

"Figma MCP is not connected. This skill requires direct Figma access. Open Claude Code → Settings → MCP Servers → add the Figma MCP → authorize. Once connected, share the frame link and we'll start." Stop completely. Do not continue with descriptions.

If no link is provided:

"Share the Figma frame link to proceed. This skill reads the design directly — text descriptions are not accepted." Stop. Do not ask follow-up questions based on descriptions.

Figma MCP calls (Step 0)

Run both:

1. get_design_context(fileKey, nodeId) — extracts all components, variants, and layers in the frame
2. get_screenshot(fileKey, nodeId) — visual reference for the full frame (used to verify layer extraction is complete)

Step 1: Extract component list from Figma

Using the get_design_context output from Step 0, extract all UI elements present in the frame. Cross-reference against the screenshot from get_screenshot to confirm the extraction is complete — flag any visible element not present in the layer data. For each extracted element, identify:

• The element type (button, input, table, chip, dialog, etc.)
• The intended behavior or variant (primary action, multi-select, paginated, dismissible, etc.)
• Any custom appearance or behavior requirements visible in the frame

Step 2: Map to Vuetify 3

For each element, perform the following check:

A. Does a Vuetify component exist?

Answer	Action
Yes, fully covered	Note component name and key props. Mark ✓
Yes, but needs customization	Note what customization is needed. Check if it's achievable via props/slots. Mark 🟡 if achievable, 🔴 if it requires DOM override
No Vuetify equivalent	Flag as ⚠️ Vuetify gap

B. Does the design use Vuetify's theming system?

• Colors must reference theme tokens (primary, error, surface, etc.), not arbitrary hex values
• Spacing should follow Vuetify's spacing scale (multiples of 4px)
• Typography should use Vuetify's text classes (text-h6, text-body-2, etc.)

C. Is the layout achievable with Vuetify's grid and flex utilities?

• Flag any layout that requires overriding Vuetify's internal structure

Step 3: For each Vuetify gap, propose options

When a gap is found:

⚠️ Vuetify gap: [component name]
Needed: [what the design requires]
Vuetify coverage: [none / partial — describe gap]
Options:
  A. [Extend existing Vuetify component via slots/CSS]
  B. [Request new component from design system maintainer]
  C. [Simplify the design to use what Vuetify provides]
Blocked: [yes — cannot proceed until resolved / no — design can proceed with option X]

Present the options to the designer. Do not choose on their behalf.

Step 4: Output the compatibility report

---

Output template

Full response (standalone or final step in chain)

## Vuetify Constraint Check: [Feature Name]

### Summary
[One paragraph: number of components checked, number of gaps found, overall status]

### Component compatibility

| UI Element | Vuetify Component | Status | Notes |
|---|---|---|---|
| [element] | v-[name] | ✓ Covered | [key props] |
| [element] | v-[name] | 🟡 Extension needed | [what needs customization] |
| [element] | — | ⚠️ Gap | [see detail below] |

### Gap details

[For each ⚠️ gap, full gap block as described above]

### Theming compliance
[✓ All colors use theme tokens / ⚠️ [element] uses hardcoded hex: [value] — replace with [token]]

### Layout compliance
[✓ All layouts achievable with Vuetify grid / ⚠️ [description of layout issue]]

### Required actions before handoff
[Numbered list of blockers that must be resolved]

Intermediate response (in chain)

Step 1 complete. Proceeding to design-handoff.
[One sentence: number of components checked, gaps found (or none), status]

---

Constraints

• Never confirm a component as covered without knowing that a Vuetify 3 equivalent exists
• Never choose between gap options on behalf of the designer — present options and wait
• Never skip theming compliance — hardcoded hex values in a design are a handoff risk
• Never ask the designer to list components manually — always extract from Figma MCP data

Context variables (populated from CLAUDE.md)

• Working language (for all prose in output)
• Design system constraints (Vuetify 3 is the hard constraint for this product)