A skill set optimized for use with Figma’s Design Agent (its custom-skill registration feature). The changelog is at the bottom of this page.
Every skill in this collection is ready to use in real production work as-is — but that’s not the only way to use it. If you want to see how a skill like this is put together, treat this repo as study material for skill-building itself. Feel free to take a skill apart, adapt it to your own environment together with an AI, or evolve it into an original skill that streamlines your own workflow. We hope you put this collection to good use.
This is the Figma-only edition of the same-named skills included in “KMRVID Claude Skills,” with the following differences:
evaluate_script); no external MCP tools are referencedSKILL.md with no reference files neededLICENSE file in each folder)| Skill | Description |
|---|---|
| brief-me | Business-requirements interview before design work begins. Useful for pinning down detailed requirements before running create-multi-pattern. Outputs the resulting BRIEF in the chat (sandbox files disappear on restart) |
| design-brief-me | Design-setting interview before design work begins (page type, typescale naming convention, base size, ratio). Where brief-me handles business requirements, this handles the setup questions figma-typescale/create-single-page would otherwise ask themselves. Checks for existing Typography settings (variables/Text Styles) up front and, if found, asks whether to carry them over — skipping the relevant questions if so. Pasting the resulting DESIGN_BRIEF alongside brief-me’s BRIEF skips every downstream question, enabling a fully unattended run |
| hey-brief-me | A picker: multi-select which of brief-me (business-requirements interview) and design-brief-me (design-settings interview) to run, and it runs only the selected ones in a fixed order (brief-me → design-brief-me). Executes each skill’s own question flow and output format as-is, with no summarizing or shortcuts. Verified on a live file — the BRIEF/DESIGN_BRIEF markdown is correctly output in the chat after each run |
| figma-typescale | Asks for a base size and ratio (Perfect Fourth, etc.) and generates a type scale. Naming convention can be “Original” (8 steps — H1–H5, body, sm, xs — matching figma-tokenize’s naming) or “Tailwind” (13 steps, font/size/xs–font/size/9xl, directly interoperable with figma-to-tailwind/tailwind-to-figma). Original mode also creates Text Styles; Tailwind mode creates variables only. In Tailwind mode, can also optionally create a fixed 4px-step Spacing scale (size/*) independent of the chosen base/ratio. Runs with no selection required; can optionally also place a preview frame with a sample of each step on the canvas, and when a frame is selected, can optionally apply the scale to its existing text. When given a design-brief-me DESIGN_BRIEF, skips the naming-convention/base-size/ratio/preview-confirmation/spacing-creation questions entirely and proceeds automatically per the DESIGN_BRIEF |
| create-single-page | The no-question version of create-multi-pattern. Paste a BRIEF and run it, and palette, typography, section composition, and structural model are all resolved by deterministic rules with zero questions, generating a single page in one pass. Because it asks nothing, it can be chained unattended: brief-me → figma-typescale → create-single-page → figma-systematize. Automatically detects and reuses any Typography variables/Text Styles already created by figma-typescale. When given a design-brief-me DESIGN_BRIEF, builds the specific page type it names (product detail, product listing, about/company page, etc.) |
| create-multi-pattern | Generates and compares multiple layout patterns at once. Passing the BRIEF above produces more refined screens. Also supports mixing multiple patterns and topology-model assignment via cognitive-ui-design integration |
| rewrite-me | Rewrites the text nodes in a selected frame/section to match a BRIEF’s requirements. Also supports adjusting text volume and (LP only) behavioral-economics persuasion framing. Never touches layout, color, or structure |
| japanese-lp-seasoning | Helps choose and represent full-bleed hero treatments, carousels/banner sliders, and vertical text as a static frame’s look. Scroll-linked reveal animation is out of scope (that’s a decision for the implementation stage) |
| figma-audit | Scores the selected frame’s AI-implementation readiness across 4 dimensions and outputs a compact report (full detail available on request) |
| figma-component-audit | Scores a single selected component/component set across 5 dimensions: variant definitions, component properties, layer naming, auto-layout, and color/typography tokens. Auto-fixes (after confirmation) two categories only: auto-generated layer names and unbound values with a matching existing variable. Meant for hand-built components (output from figma-componentize/figma-enhance doesn’t need this) |
| figma-layer-rename | Detects auto-generated layer names (like Frame 12) and renames them to semantic names after confirmation. Names that aren’t auto-generated but are duplicated among siblings (like Container or Section) can optionally also be targeted for differentiating renames |
| figma-tokenize | Converts hardcoded colors, font sizes, and spacing into bound variables (tokens) |
| figma-componentize | Detects repeating patterns within the selected frame (buttons, cards, list items, etc.), proposes componentization, and after confirmation interactively builds a master component + instance replacement, variant generation (State/Style/Size, etc.), and variable-binding for those variants. Headers/footers are judged by position and role (top/bottom of the frame, full width) rather than repeat count, so they’re candidates even if they appear only once per frame |
| figma-systematize | Processes the selected frame through a 3-stage pipeline: layer naming → tokenization → componentization. Inlines the equivalent logic of figma-layer-rename → figma-tokenize→ figma-componentize into a single skill (to avoid the instability of chaining skills together), asking once up front whether to run automatically or confirm each step. The componentization phase also judges headers/footers by position and role rather than repeat count, so they’re candidates even at one occurrence per frame (so create-single-pagecan reuse them as instances when adding another page later) |
| figma-enhance | Audits an already tokenized/componentized file across the whole page and detects, proposes, and implements further improvements (variant-merge candidates, missing component properties, unbound variables, unapplied Text Styles, unnecessary fills). Meant as the “next step” after running figma-systematize, etc. |
| hey-optimize-me | A picker: multi-select which of tidy-up / figma-layer-rename / figma-tokenize / figma-componentize / figma-enhance to run, and it runs only the selected ones in a fixed order (tidy-up → rename → tokenize → componentize → enhance), pausing at each one’s own confirmation steps along the way. Where figma-systematize inlines rename/tokenize/componentize into one skill for a fully unattended run (tidy-up/enhance aren’t part of it), this one is for when you want to confirm each step and only run a subset of the five tasks. Verified on a live file |
| figma-alt-suggest | Detects every node with an IMAGE fill within the selected frame (regardless of layer name), looks at the actual rendered content, and proposes a specific alt-text draft for each. Judges purely decorative images (icons that duplicate an adjacent label, background textures, etc.) as needing no description. Always presents a report first; after confirmation, can optionally also write the suggestions as Dev Mode annotations in the Accessibility category (marked with a **ALT suggestion:** tag so it doesn’t collide with figma-annotate’s own idempotency check) |
| figma-annotate | Writes native Figma Dev Mode annotations (Development/Accessibility/Content preset categories) across the selection, passing a coding agent implementation intent the structure alone can’t convey. Anything the design can determine automatically — layout/CSS inferred from auto-layout, ARIA patterns for detected carousels/forms, image object-fit/aspect-ratio, etc. — is written automatically; anything the design alone can’t answer (CMS scope, validation rules, destination URLs) is written as an explicit “Needs confirmation” annotation instead of a guess. Idempotent — skips nodes that already have an annotation in the same category. ALT text is out of scope (pairs with figma-alt-suggest). Writes only after confirmation |
| figma-contrast-check | Checks WCAG contrast ratios (AA/AAA switchable) for text within the selected frame and outputs a compact report (full detail available on request). Also supports an advisory check for non-text UI elements and auto-fixing failing colors |
| figma-design-md | Two-way sync between DESIGN.md (following the Google design.md spec) and a Figma file. Import: builds variable collections, Text Styles, and components from an attached DESIGN.md. Export: generates a DESIGN.md from the current file’s variables, Text Styles, and components. Mode is auto-detected based on whether a DESIGN.md is attached (only asks when none is attached) |
| figma-japanese-web-guideline | Guideline for correcting the defaults AI tends to fall into when creating or editing a Japanese-language website design in Figma (unwanted italics, centered-text wrapping breaks, over-wide line-height, culturally-off color choices, etc.). Reference during design generation and review. The Figma-only edition of japanese-web-guideline (which covers code-level implementation) from “KMRVID Claude Skills.” Note: unlike the rest of this edition, the guideline’s rule content itself (the rule text, tables, and checklist) stays in Japanese here too, since it documents Japanese-typography-specific rules that risk misinterpretation in translation — only the questions/reports around it are in English |
| figma-mobile-convert | Generates a mobile version (390px width) from a desktop-size (1280–1440px width) frame. Pre-checks readiness (layer names/variable binding/componentization) and, if it falls short, recommends running figma-systematize first. Heading font weight, section background color, and full-bleed images must exactly match the desktop — only size, layout, and spacing may change. Determines the nav pattern (horizontal menu → hamburger/bottom tab bar/drawer) from site type and item count, and builds it as a variant-based component. Ports the design philosophy of mobile-polish (code-level implementation) from “KMRVID Claude Skills” into Figma |
| figma-i18n-translator | A pre-implementation layout check — the actual multilingual build/translation belongs in code. Duplicates the selected frame/section once per language and translates every text node, including inside INSTANCEs. Source language is auto-detected; target languages are chosen from a preset (English/Spanish/French/German/Portuguese/Chinese Simplified/Japanese/Korean, multi-select) plus free text. Duplicated frames are named <original name>_<language code> (e.g. Home_en). Sets each translated node’s text-wrap style (BALANCE for headings, PRETTY for body copy) to reduce orphaned words and uneven headings, and resets Japanese-specific JUSTIFIED alignment to LEFT when duplicating away from Japanese. Warns before running if the frame lacks auto-layout (translated text may break the layout) and reminds the user to visually check afterward — deliberately has no auto-fix logic for layout breakage or for protecting numbers/proper nouns |
| coding-prompter | Generates an implementation prompt for a coding agent from a selected frame whose design is finished. First checks whether the user has “KMRVID Claude Skills” — if so, it just presents one of /figma-pipeline, /figma-workflow, or /figma-update-checker depending on the task (new build / add a page to an existing environment / update a file), and it’s done. If not, it interviews the user for the tech stack (new environment) or details about the existing environment (framework, CSS approach, coding guidelines, directory structure), then assembles an implementation prompt covering the design reference (fileKey/nodeId), image assets (fetch real images with download_assets), design tokens (use variables/styles/components where present), and following annotations. Includes all selected node IDs when multiple frames are selected |
| slot-table-maker | No selection needed. Interviews for column and row count, then generates a fixed-header, variable-data-row table component system. Built from 5 components — Table/HeaderCell, Table/DataCell, Table/HeaderRow, Table/DataRow (3 variants: State=Default/Hover/Selected), and Table/Table — with row count and content made variable via a “Rows” slot on the Table. To add or remove columns, edit the cell instances inside HeaderRow/DataRow directly (column count is handled through component editing, not a slot) |
| agent-handoff | No selection needed — operates on the conversation itself, not the canvas. Not an auto-executing program: when invoked, the agent reads its instructions and reviews the entire conversation history, then outputs a Markdown handoff document (target file/nodes, conversation summary, completed work, pending next steps, key decisions & constraints, user preferences & working style, tried-and-failed approaches, relevant custom skills used, and other notes) inside a single fenced code block. The user pastes that block as the first message in a new chat session to continue seamlessly, without re-explaining context |
| hey-be-careful | No selection needed — a guideline targeting the agent’s own behavior rather than the canvas. Once invoked, enforces six rules for the rest of the chat session: ask the user when anything is unclear, follow skill steps in order without skipping, always verify carefully, ask questions one at a time, share the plan before multi-step work, and report completions specifically. Meant to be invoked at the start of a new chat or whenever more careful, deliberate work is needed |
| tidy-up | Restructures a selected frame or component (multi-selection supported) into an auto-layout-based hierarchy with clean layer names and normalized spacing. Captures a “before” screenshot and a per-element spacing map first, then distinguishes macro-level layout rhythm (preserved, rounded to the 4px grid) from micro-level misalignment (corrected via auto layout’s own alignment, inferring CENTER/MIN/MAX from position bias). Rebuilds by moving existing nodes into new structural frames with appendChild (never remove()), then iterates a screenshot-compare-fix cycle until the macro-level result matches the original. Checks the file for existing variables/styles and reports them without binding — recommends running figma-tokenize afterward for that. Meant for manually positioned designs with no auto layout applied |
| hey-polish-me | Analyzes an already-finished frame (whole page or a single section) and produces an improvement proposal without touching the original. Checks in one batch whether cognitive-ui-design (eye-flow/information-hierarchy redesign), create-multi-pattern(comparing structurally different proposals), and rewrite-me (BRIEF-aligned copy rewrite) are available as optional companion skills, and presents only the combinations that are actually usable. Classifies every improvement decision’s evidence into observed on-screen fact / BRIEF / general principle / hypothesis, and never asserts a fabricated survey, statistic, or effect. Confirms non-obvious Plugin API property names against the local typings before writing, and treats proposal creation as a transaction — on a failed write it removes only the current run’s own incomplete copy before retrying. Output can be a report, native Dev Mode annotations (Content category), or both. Verified on a live file |
| create-jp-lp | Generates a single Japanese commercial landing-page (LP) frame, applying conventions specific to Japanese commercial LPs: appeal-genre classification (world-view/brand-driven vs. direct-response), industry-specific palette/CTA-color rules, and image-handling conventions (whether headings are baked into images, how far full-bleed backgrounds extend, culturally-specific motifs like problem-awareness icon cards). Runs independently of create-single-page/create-multi-pattern — makes no changes to either. Infers appeal genre and industry from the BRIEF’s free text and applies a palette/section structure grounded in real-example research. When no brand color is given, weighs several distinct hue candidates before choosing one, to avoid the generic-looking color convergence generative AI tends to default to. Always applies constraints that keep the output implementable in Tailwind without exotic techniques (bounded full-bleed range, headings baked as single flat image assets, etc.), and verifies WCAG AA contrast on CTA colors and height consistency across differently-structured cards in the same row after generation. Checks in one batch whether cognitive-ui-design/figma-japanese-web-guideline are available as optional companion skills and presents only the usable ones. Note: the rule content itself (convention tables, Step instructions) stays in Japanese here too, for the same reason as figma-japanese-web-guideline — only the questions/reports around it are in English. Verified on a live file |
※ The cognitive-ui-design skill is included in the regular “KMRVID Claude Skills” package but is not part of this Figma-only edition (create-multi-pattern, hey-polish-me, and create-jp-lp reference it as an optional companion skill — if you want to use it, register cognitive-ui-design’s SKILL.md from “KMRVID Claude Skills” as a separate custom skill). japanese-web-guideline is included here as its Figma-optimized counterpart, figma-japanese-web-guideline.
SKILL.md of whichever skill you want to use, via Figma’s custom-skill registration feature