Documentation Index
Fetch the complete documentation index at: https://docs.lintkit.com/llms.txt
Use this file to discover all available pages before exploring further.
- Quick Reference
- Cheat Sheet
- Full Guide
- How to Fix
- AI Prompts
At a glance
If LintKit’s component replacement isn’t working as expected, your library probably has one or more of these issues:- Generic property names like
Property 1that were never renamed - Components named by color or appearance instead of purpose
- Inconsistent size or state labels across families
TypeorVariantmeaning different things in different components- Internal helpers published alongside real components
- Duplicate semantic paths
- Version suffixes like
_finalor_v2baked into published names
What good naming looks like
Name by purpose, not appearance
| Instead of this | Use this |
|---|---|
Blue Button | Button/Primary |
Green Alert | Alert/Success |
Gray Tag | Badge/Neutral |
Use forward slashes for meaningful paths
- Good:
Actions/Button/Primary/MD/Default - Bad:
button primary medium final
Use consistent variant property names
Use the same axes across your library:| Property | Purpose | Example values |
|---|---|---|
Style | Visual hierarchy | Primary, Secondary, Ghost |
Size | Component scale | SM, MD, LG |
State | Interaction status | Default, Hover, Disabled |
Modifier | Optional configuration | Full width, With label |
Use affirmative booleans for component properties
- Good:
Show icon,Is loading,Has label - Also good:
showIcon,isLoading,hasLabel - Bad:
Icon=True,Label?,Hide Icon
Hide internal helpers
- Good:
.Button Base,_Input Shell - Bad: Publishing every internal atom and fragment
Pick a casing convention and stick to it
- Title Case is most natural for designers in Figma
- camelCase works for developer-aligned teams
- The problem is mixing both in the same library
Rename these before publishing
These are Figma defaults or implementation leftovers that should never appear in a published library:Property 1,Property 2— rename toStyle,Size,State, etc.- Unrenamed
VariantorType— rename to describe what the axis actually controls Frame 104,Component 7— replace with semantic namesButton_final_v2— archive the old version, keep one canonical componentBlue Button,Green Alert— use role names likePrimaryandSuccessSlot A,Area 1— use role names likeHeader,Content,Footer
Comparison examples
| Component | Acceptable | Unacceptable |
|---|---|---|
| Button | Actions/Button/Primary/MD/Default | Blue Button/final/Property 1=Primary |
| Input | Data Entry/Input/Text/MD/Default | Input Field/Component 7/Property 2=Medium |
| Checkbox | Data Entry/Checkbox/Checked/Enabled | Box/On/Property 2 |
| Alert | Feedback/Alert/Critical/With Icon | Notice/Red/Icon=True |
| Modal | Overlays/Modal/Dialog/MD/Default | Popup/Overlay/Frame 102 |
| Badge | Feedback/Badge/Success/SM | Tag/Green/12px |
| Switch | Data Entry/Switch/On/Enabled | Toggle/Variant=On/Frame 22 |
Quick fixes (in priority order)
- Rename generic properties first —
Property 1→Style,Property 2→Size, etc. This is the highest-impact change. - Pick one size system —
XS / SM / MD / LG / XLacross every family - Pick one state system —
Default / Hover / Focused / Disabled / Erroracross every family - Remove version suffixes — archive old versions, keep one canonical component
- Hide internal helpers — prefix with
_or., or use “Hide when publishing” - Name slots by role —
Header,Content,Footerinstead ofSlot A,Area 1 - Settle on a casing convention — Title Case or camelCase, not both in the same library
Recommended standards
- Every public component should have a stable, semantic path
- Variant property names should be descriptive and consistent across families
- Boolean component properties should be affirmative (
Show icon, notHide icon) - Internal helpers should not appear in the assets panel or Replace Component
- Duplicate semantic paths should be resolved — one canonical version per component
- Name by role, not by color, when the name represents a semantic purpose
Simple rule to remember: Name components the way a designer chooses them, not the way Figma generated them.
Find & Replace
LintKit’s Find & Replace lets you search layer names, style names, or component names and swap matched text. Works with plain text or regex. Choose a target (layers, styles, or components) and scope (selection, page, or document).Remove copy suffixes
Strips the “copy” or “Copy 2” suffixes Figma adds when you duplicate layers.| Before | Find (regex) | Replace | After |
|---|---|---|---|
Card_copy | [_\s-]?copy(\s*\d+)?$ | (empty) | Card |
Header copy 3 | [_\s-]?copy(\s*\d+)?$ | (empty) | Header |
Nav-copy 12 | [_\s-]?copy(\s*\d+)?$ | (empty) | Nav |
[_\s-]? matches an optional separator before “copy”, copy matches the literal word, (\s*\d+)? optionally matches a space and number, and $ anchors to the end of the name.Strip default Figma names
Replaces auto-generated names like “Frame 47” with a meaningful name. Scope to Selection so you only affect the layers you’ve chosen.| Before | Find (regex) | Replace | After |
|---|---|---|---|
Frame 47 | ^Frame\s+\d+$ | Card | Card |
Rectangle 12 | ^Rectangle\s+\d+$ | Background | Background |
Group 3 | ^Group\s+\d+$ | Row | Row |
^ anchors to the start, Frame is the literal word, \s+\d+ matches space plus digits, and $ anchors to the end (so “Frame Header” won’t match).Remove temporary prefixes
Strips WIP, DRAFT, DELETE, OLD markers before handoff.| Before | Find (regex) | Replace | After |
|---|---|---|---|
WIP Button Primary | ^(WIP|DRAFT|DELETE|OLD|REMOVE)[\s_-]+ | (empty) | Button Primary |
DRAFT-Header | ^(WIP|DRAFT|DELETE|OLD|REMOVE)[\s_-]+ | (empty) | Header |
Clean up version suffixes
Removes_v2, _final, NEW, and other naming debt.| Before | Find (regex) | Replace | After |
|---|---|---|---|
Card_v2 | [_\s-]?v\d+$ | (empty) | Card |
Header_final | [_\s-]?(final|FINAL)$ | (empty) | Header |
Button NEW | \s+(NEW|new|Old|OLD)$ | (empty) | Button |
Convert separators
Switch between dashes, underscores, and slashes. Plain text mode works — no regex needed.| Before | Find | Replace | After |
|---|---|---|---|
icon_arrow_left | _ | / | icon/arrow/left |
button-primary-large | - | / | button/primary/large |
Icon/Arrow/Left | / | - | Icon-Arrow-Left |
Add or change prefixes
Organize names into folder hierarchies using regex capture groups.| Before | Find (regex) | Replace | After |
|---|---|---|---|
Primary | ^(.+)$ | Button/$1 | Button/Primary |
Shadow Soft | ^(.+)$ | Effects/$1 | Effects/Shadow Soft |
Colors/Blue/500 | ^Colors/ | Color/ | Color/Blue/500 |
^(.+)$ captures the entire name as $1. In the replace field, Button/$1 puts “Button/” before the captured text.Restructure component paths
Rearrange slash-separated segments using capture groups.| Before | Find (regex) | Replace | After |
|---|---|---|---|
Primary/Button | ^([^/]+)/([^/]+)$ | $2/$1 | Button/Primary |
Button/Primary | ^(Button|Input|Select) | Data Entry/$1 | Data Entry/Button/Primary |
Icons/UI/Arrow Left | ^Icons/UI/ | Icons/ | Icons/Arrow Left |
Reorganize style names
Target set to Styles. Style names control folder structure in Figma’s style picker.| Before | Find (regex) | Replace | After |
|---|---|---|---|
clr-blue-500 | ^clr- | Color/ | Color/blue-500 |
typ-heading-lg | ^typ- | Typography/ | Typography/heading-lg |
Colors/Brand/Primary/Blue/500/Default | ^Colors/Brand/Primary/ | Color/ | Color/Blue/500/Default |
Batch Rename (Template Variables)
Batch Rename works differently — instead of searching for text, it renames all layers in a finding using a template that pulls info from each layer automatically.Available variables
| Variable | What it inserts | Example |
|---|---|---|
{name} | Current layer name | Header, Frame 47 |
{type} | Layer type | Frame, Text, Rectangle |
{n} | Sequential number | 1, 2, 3 |
{nn} | Zero-padded number | 01, 02, 03 |
{nnn} | Zero-padded 3 digits | 001, 002, 003 |
{parent} | Parent layer’s name | Card, Header, Root |
{w} | Width in pixels | 320, 48 |
{h} | Height in pixels | 240, 900 |
{page} | Page name | Homepage, Components |
Built-in presets
| Preset | Template | Example output |
|---|---|---|
| Item List | Item {n} | Item 1, Item 2, Item 3 |
| With Parent | {parent} / Item {n} | Card / Item 1, Card / Item 2 |
| Type + Number | {type} {nn} | Frame 01, Text 02 |
| Size-based | {type} {w}x{h} | Rectangle 320x48 |
Examples
Sequential naming — template:Card {nn}| Before | After |
|---|---|
Frame 47 | Card 01 |
Frame 48 | Card 02 |
Frame 49 | Card 03 |
{parent} / {type} {n}| Parent | Before | After |
|---|---|---|
Card | Frame 1 | Card / Frame 1 |
Card | Text 3 | Card / Text 2 |
Header | Group 5 | Header / Group 1 |
Icon {w}x{h}| Before | Dimensions | After |
|---|---|---|
Vector 1 | 16×16 | Icon 16x16 |
Vector 2 | 24×24 | Icon 24x24 |
Vector 3 | 32×32 | Icon 32x32 |
Regex Quick Reference
| Pattern | What it matches | Example |
|---|---|---|
^ | Start of name | ^Icon matches “Icon/Arrow” but not “My Icon” |
$ | End of name | copy$ matches “Card copy” but not “copyright” |
. | Any single character | v.2 matches “v.2” and “v12” |
\d | Any digit | \d+ matches “47” in “Frame 47” |
\s | Any whitespace | \s+ matches spaces and tabs |
\w | Letter, digit, or underscore | \w+ matches “Button” |
+ | One or more | \d+ matches “1”, “47”, “123” |
* | Zero or more | \s* matches "" or ” “ |
? | Zero or one | \s? matches "" or ” “ |
(...) | Capture group | (Button) → use $1 in replace |
(a|b) | Either a or b | (WIP|DRAFT) matches either |
[abc] | Any one character | [_\s-] matches _, space, or - |
[^abc] | Any character except | [^/]+ matches up to a / |
Replace patterns
| Replace with | What it does |
|---|---|
| (empty) | Deletes matched text |
$1 | Inserts the first capture group |
$2 | Inserts the second capture group |
$1/$2 | Combines two groups with a slash |
Prefix/$1 | Adds a prefix before captured text |
Tips
- Preview first. Always use “Find Only” before applying to see what will change.
- Scope to Selection. Generic patterns like
^Frame\s+\d+$can match things you don’t expect — narrow scope first. - Work in passes. Multiple simple find-and-replaces beat one complex regex.
- Styles are file-scoped. When targeting Styles, the scope setting doesn’t apply — styles are always file-level.
Who this guide is for
This guide is for design system teams, product designers maintaining shared libraries, design ops teams cleaning up legacy component files, and anyone using LintKit’s component replacement features.LintKit works best when your library names describe what a component is and how a designer would choose it, not how Figma happened to generate it.How naming quality affects LintKit
LintKit can do a much better job when your library is semantic, consistent, scannable, machine-readable, and cleanly separated between public and internal assets.In practice, that means your library should have:- Stable component paths
- Meaningful page and section structure
- Predictable variant property names
- Controlled vocabularies for values
- Affirmative boolean labels
- Unique semantic paths
- Internal helpers hidden from publishing
LintKit will likely struggle when it sees
Property 1, duplicate paths, Type used inconsistently, helper contamination, or icons and templates mixed into public component pages.Semantic naming vs. implementation naming
Semantic naming describes what a component is, what role it plays, and what choices a designer is making:Button/PrimaryInput/SearchAlert/Success
Blue ButtonFrame 104Property 1=PrimaryButton_Final_v2
Blue Button becomes wrong. Button/Primary stays correct.Library structure
A usable library depends on five layers working together:- File — e.g.
Product Design System - Page — e.g.
Data Entry - Section / frame — e.g.
Inputs - Component path — e.g.
Input/Search - Variant properties — e.g.
Size=MD,Style=Filled,State=Default
Use slashes for stable paths
Forward slashes should create meaningful groupings, not word salad.- Good:
Actions/Button/Primary/Medium/Default - Bad:
button-primary-medium-state-1
Recommended top-level categories
Pick a small set and stick to it:ActionsData EntryNavigationData DisplayFeedbackOverlaysLayoutFoundationsorPrimitives
Do not create both
Forms and Data Entry unless you have a strict rule for the difference. Category drift is how libraries turn into attic boxes labeled “misc.”The “Big Four” semantic axes
Most reusable UI components can be described using four consistent property types.1. Style
The visual hierarchy or treatment.Primary,Secondary,Ghost,Outline,Filled
2. Size
The scale of the component.XS,SM,MD,LG,XL
3. State
The current interaction or status.Default,Hover,Focused,Pressed,Disabled,Error,Selected,Checked
4. Modifier
Optional toggles or additions.Has Icon,Allow Clear,Loading,Full Width,Show Label
Type=Primary, State=Hover, Size=Large but another uses Variant=Main, Status=Over, Scale=LG, your library becomes harder for designers to scan and harder for tooling to normalize.Size vocabulary
Use T-shirt sizes as the default:XS,SM,MD,LG,XL
What to avoid
What to avoid
Do not mix
Use relative size meaning, not raw build values.
Small, sm, S, 16, and Regular as if they are interchangeable.| Approach | Example |
|---|---|
| Good | Size=SM, Size=MD, Size=LG |
| Workable | Size=Small, Size=Medium, Size=Large |
| Avoid | Size=16, Size=2, Size=Default, Size=Regular when you already use MD elsewhere |
Overloaded property names: the “Type” problem
Type is one of the most overloaded names in component libraries. It might mean style, subtype, status, treatment, or even state.In one family Type=Primary means visual hierarchy. In another, Type=Search means input subtype. In another, Type=Success means feedback tone. Those are three different semantic jobs wearing the same name.Use more specific property names:| Instead of | Use |
|---|---|
Type=Primary | Style=Primary |
Type=Search | Subtype=Search |
Type=Success | Tone=Success |
Boolean naming
Boolean properties should read like a clear yes/no question. Use affirmative prefixes:is, has, show.| Bad | Better |
|---|---|
Hide Icon | showIcon |
Visible | isVisible or showContent |
Label? | hasLabel |
Selected | isSelected |
Hide Icon and the value is true, what does that mean? That ambiguity is error-prone. Flip to showIcon so true means “the icon is visible.”Slots and sub-parts
Complex components often expose slots, instance swaps, or nested subcomponents. Those names must still be semantic.| Bad | Better |
|---|---|
Area 1 | Header |
Slot A | Content |
Frame 12 | Footer |
Section B | Leading icon |
Custom Area | Supporting text |
Header means something. Area 1 means nothing.Public vs. internal components
One of the biggest reasons Replace Component gets messy is helper contamination. Internal parts, slots, atoms, fragments, and scaffolding should not appear in the assets panel.Public components are things users actually insert: Button, Input, Card, Badge, Modal, Alert.Internal helpers should stay hidden: button bases, icon glyph wrappers, row fragments, cells, scaffolds, layout shells.Hide internal-only pieces using:.prefix (e.g..Button Base)_prefix (e.g._Input Shell)- Figma’s “Hide when publishing” behavior
Casing conventions
Pick one and keep it everywhere:- Title Case is most natural for designers in Figma
- camelCase works for developer-aligned teams
- The problem is mixing both in the same library
Library smell checklist
If your library has these issues, semantic replacement gets less reliable.Top 10 library smells
Top 10 library smells
- Generic property names —
Property 1,Property 2,Variant - Duplicate semantic paths — two different component sets resolve to the same human meaning
- Versioning rot —
_final,_v2,_new,_old - Inconsistent casing — mixing camelCase, kebab-case, Title Case, and UPPERCASE inside the same family
- Helper contamination — internal atoms or fragments mixed with public components
- Color-based naming —
Green Button,Blue Badge,Red Alert - Project-management naming —
Ready for Dev,Use This One,New,Final Final, initials, emojis, sprint notes - Overloaded
Type— same label used for different semantic jobs - Long slash spaghetti — paths so deep they stop being readable
- Component copies with no clear canonical version —
CardV2,Card Final,Card final copy,Card fixed
Full comparison table
These are one-to-one comparisons of the same component, showing a clean semantic path and an implementation-heavy version.24 component examples
24 component examples
| Component | Acceptable | Unacceptable |
|---|---|---|
| Button | Actions/Button/Primary/MD/Default | Blue Button/final/Property 1=Primary |
| Icon Button | Actions/Button Icon/Primary/MD/Default | Button Icon/16px/blue/v2 |
| Link | Actions/Link/Inline/Default | Blue Text Link/Variant 2 |
| Text Input | Data Entry/Input/Text/MD/Default | Input Field/Component 7/Property 2=Medium |
| Search Input | Data Entry/Input/Search/MD/Filled/Allow Clear | SearchBox/Type=Active/Size=2/Helper 01 |
| Textarea | Data Entry/Input/Textarea/MD/Default | Textarea/Property 1=Default/Copy 3 |
| Select | Data Entry/Select/MD/Default | Dropdown/Type=Primary |
| Checkbox | Data Entry/Checkbox/Checked/Enabled | Box/On/Property 2 |
| Radio | Data Entry/Radio/Checked/Disabled | Radio/Status=Active/Type=Disabled Checked |
| Switch | Data Entry/Switch/On/Enabled | Toggle/Variant=On/Frame 22 |
| Tabs | Navigation/Tabs/Line/MD/Default | Tabs/Default/Container Tabs |
| Breadcrumbs | Navigation/Breadcrumbs/Default | Nav Path/Variant 1 |
| Badge | Feedback/Badge/Success/SM | Tag/Green/12px |
| Alert | Feedback/Alert/Critical/With Icon | Notice/Red/Icon=True |
| Toast | Feedback/Toast/Success/Default | Alert Green/State 1 |
| Modal | Overlays/Modal/Dialog/MD/Default | Popup/Overlay/Frame 102 |
| Drawer | Overlays/Drawer/Right/MD/Default | Slideout/Right thing/new |
| Tooltip | Data Display/Tooltip/Default | Tooltip/Helper/Do Not Use |
| Card | Data Display/Card/User Profile/Default | CardV2/user_info/final |
| Table | Data Display/Table/Default | Table/Row Fragment/Cell 02 |
| Spinner | Feedback/Spinner/LG/Default | Loading/Wheel/32px |
| Progress | Feedback/Progress/Linear/Default | Loader Bar/state-3 |
| Avatar | Data Display/Avatar/User/MD | Profile Pic 40 |
| Pagination | Navigation/Pagination/Default | Page Nav/control set 4 |
Quick fix guide
Use this when your library is already messy and you need to improve it fast.Fix 1: Rename generic properties first. If you seeProperty 1, Property 2, or Variant, rename them immediately to Style, Size, State, Modifier, Tone, or Subtype.Fix 2: Standardize size naming. Pick XS/SM/MD/LG/XL or Small/Medium/Large, then update every similar family to match.Fix 3: Standardize state naming. Choose one set: Default, Hover, Focused, Pressed, Disabled, Error, Selected, Checked. Avoid mixing Rest, Base, Normal, and Default.Fix 4: Remove version suffixes. Replace _v2, _final, _new — archive the old version, keep one canonical published component.Fix 5: Hide internal helpers. Prefix internal-only components with . or _, or hide them from publishing.Fix 6: Move organization out of bloated names. If component paths are getting too long, move grouping into pages and sections.Fix 7: Add descriptions to public components. Descriptions help users understand when to use it, when not to, and what conventions it follows.Non-negotiable rules
- Never publish
Property 1,Property 2, orVariantas-is - Every public component must have a stable semantic path
- Use one controlled vocabulary for size
- Use one controlled vocabulary for state
- Boolean properties must be affirmative and explicit
- Internal helpers must be hidden from the public library
- No duplicate semantic paths
- Do not name by color if the name represents a role
- Do not use version suffixes as a permanent naming strategy
- Slots must be named by role, not by position or placeholder
What “good” looks like
A healthy public component family:Actions/Button
├── Style = Primary | Secondary | Ghost
├── Size = SM | MD | LG
├── State = Default | Hover | Disabled
├── hasIcon = True / False
└── isLoading = True / False
Data Entry/Input/Search
├── Style = Filled | Outline
├── Size = SM | MD | LG
├── State = Default | Focused | Error | Disabled
├── allowClear = True / False
└── showLeadingIcon = True / False
If you want Replace Component to feel smart, your library has to stop speaking in implementation leftovers and start speaking in product language. The goal is easier browsing, fewer mistakes, better design-to-code parity, and cleaner replacement results.
What LintKit detects
LintKit’s naming rule catches three categories of problems:- Default Figma names —
Frame 47,Rectangle 12,Group 7,Text 3, and other auto-generated names that tell developers nothing about the layer’s purpose. - Forbidden patterns — copy suffixes (
Button copy 2), temp labels (WIP Header,TODO fix this), and other placeholders that should never appear in a published file. - Convention violations — when your file has a dominant naming style (like
camelCase) and some layers break it (likehero-bannerin kebab-case).
Fixing component variant properties
Variant properties are the dropdowns designers see when selecting a variant. Default names likeProperty 1 give no context about what the property controls.Select the component set in your library file
Click the component set (the purple dashed border) — not an individual variant inside it.
Open the Design panel
Look for the variant property names listed under the component set name. You’ll see names like
Property 1, Property 2, etc.Rename the property
Click the property name to edit it. Replace generic names with descriptive ones:
Property 1→StyleProperty 2→Size
Button component set
├── Property 1 = Primary
├── Property 1 = Secondary
├── Property 2 = Default
├── Property 2 = Hover
Button component set
├── Style = Primary
├── Style = Secondary
├── State = Default
├── State = Hover
Fixing component boolean properties
Boolean properties control toggles like “show icon” or “is loading.” Default names likeProperty 3 don’t communicate what the toggle does.Select the individual component
Click the component itself (not the component set) — the one with the purple diamond icon.
true or false — you only need to rename the property itself.Before:Property 3 = true/false
Show icon = true/false
Fixing slot and sub-layer names
Slots and sub-layers are the internal parts of a component that designers can customize. Default names likeFrame 12 make it impossible to know which slot does what.Before:
Frame 12
Group 4
Rectangle 1
Header
Content
Background
Hiding internal helpers
Internal components (button bases, icon wrappers, layout scaffolds) clutter the assets panel and confuse Replace Component. Three ways to hide them:Option A: Prefix with . or _
Rename the component to
.Button Base or _Input Shell. Figma automatically hides dot-prefixed components from library publishing.Option B: Right-click → Hide when publishing
Right-click any component in a library file and select Hide when publishing. The component stays usable inside the file but won’t appear in the assets panel for consumers.
Simple rule: If a component is mainly used inside another component, it probably should not appear in your library’s assets panel.
Bulk renaming layers with Figma’s built-in tools
For large files with many default names, Figma’s native bulk rename is the fastest path.Select the layers to rename
Select multiple layers in the layers panel, or press Cmd/Ctrl+A to select all layers on the current page.
Choose a rename pattern
You have several options:
- Replace all names: Type a new name. All selected layers get that name.
- Keep current name with prefix/suffix: Use
$&to reference the current name. For example,Section/$&wraps every name with a category prefix. - Find and replace: Use the Match field with a regex pattern and the Replace field to fix specific problems.
Useful find-and-replace patterns
| Goal | Match | Replace with |
|---|---|---|
| Remove ” copy” suffixes | copy\s*\d*$ | (empty) |
| Remove ” - old” suffixes | \s*-\s*old$ | (empty) |
| Add a category prefix | (select layers, type new name) | Section/$& |
LintKit also has a built-in Batch Rename feature that works directly from naming findings. It supports pattern tokens like
{n}, {parent}, and {type} for more structured renaming.Standardizing size values across a library
When different component families use different size labels (Small, sm, S, 16), the library feels inconsistent and tooling can’t match across families.Pick one size vocabulary
The most common choice is T-shirt sizes:
XS, SM, MD, LG, XL. Alternatively, use Small, Medium, Large — but pick one and stick to it.Open each component set with a size property
Go through your library and find every component set that has a size variant.
Rename each variant value to match
Click the variant value in the Design panel and rename it:
Small→SMMedium→MDLarge→LG
Handling version suffixes
When you find components likeCard_v2, Card Final, Card fixed, it means the library has accumulated drafts that were never cleaned up.Decide which is the canonical version
Look at which version is most widely used across your files. That’s your canonical component.
Archive the old versions
Move old versions to a page called
_Archive or _Deprecated. This keeps them accessible but out of the main library.Rename the canonical version
Remove the version suffix:
Card_v2 → Card. This is now the single source of truth.Migrate existing instances
If instances of the old version exist in consumer files, use Figma’s Swap component feature to migrate them to the canonical version.
Before deleting old component versions, use Figma’s Go to main component on existing instances to make sure nothing is still pointing at the version you’re about to remove.
Use these ready-made prompts with Claude or ChatGPT to generate the exact regex patterns you need for LintKit’s Find & Replace. Copy the prompt, fill in the [BRACKETED] placeholders with your values, and paste it into the AI.
The more before/after examples you include, the better the AI’s output will be. Always test with LintKit’s “Find Only” mode before applying.
Remove a suffix from layer names
Best for: Cleaning up copy suffixes, version markers, status tags, or any repeated suffix across many layers.Example result:| Before | After |
|---|---|
Card_copy | Card |
Header copy 3 | Header |
Nav-copy 12 | Nav |
Copy this prompt
I'm using a Figma plugin called LintKit that has a Find & Replace
feature with regex support. I need to remove the suffix [YOUR SUFFIX]
from my layer names. It might appear with a separator before it
(space, dash, or underscore).
Examples of names I have:
- [EXAMPLE 1, e.g. "Card_copy"]
- [EXAMPLE 2, e.g. "Header copy 3"]
- [EXAMPLE 3, e.g. "Nav-copy 12"]
Give me the Find pattern (regex) and the Replace pattern to use
in LintKit's Find & Replace. The suffix should only be removed
from the end of the name, not the middle.
Replace default Figma names with a meaningful name
Best for: Replacing auto-generated names like “Frame 47” or “Rectangle 12” with semantic names, scoped to your current selection.Example result:| Before | After |
|---|---|
Frame 47 | Card |
Frame 12 | Card |
Frame 203 | Card |
Copy this prompt
I'm using LintKit's Find & Replace with regex. I have layers with
Figma's default auto-generated names and I want to replace them
with a specific name.
Default names to match: [e.g. "Frame 1", "Frame 2", "Frame 47"]
Replace them all with: [e.g. "Card"]
The pattern should only match the exact default format (the word
followed by a space and number), not names like "Frame Header"
or "My Frame".
Give me the Find pattern (regex) and the Replace value.
Remove a prefix from layer names
Best for: Stripping WIP, DRAFT, DELETE, OLD, or any temporary markers before handoff or publishing.Example result:| Before | After |
|---|---|
WIP Button Primary | Button Primary |
DRAFT-Header | Header |
OLD_Sidebar Nav | Sidebar Nav |
Copy this prompt
I'm using LintKit's Find & Replace with regex. I need to remove
a prefix from the beginning of my layer names. The prefix might
be followed by a space, dash, or underscore.
Prefixes to remove: [e.g. "WIP", "DRAFT", "OLD", "DELETE"]
Examples:
- [e.g. "WIP Button Primary" should become "Button Primary"]
- [e.g. "DRAFT-Header" should become "Header"]
Give me the Find pattern (regex) and the Replace value.
Clean up version or status suffixes
Best for: Removing_v2, _final, NEW, old, and other naming debt accumulated over time.Example result:| Before | After |
|---|---|
Card_v2 | Card |
Header_final | Header |
Button NEW | Button |
Copy this prompt
I'm using LintKit's Find & Replace with regex. I need to remove
version and status markers from the end of my layer names.
Suffixes to remove: [e.g. "_v2", "_final", " NEW", " old"]
Examples:
- [e.g. "Card_v2" should become "Card"]
- [e.g. "Header_final" should become "Header"]
- [e.g. "Button NEW" should become "Button"]
Give me the Find pattern (regex) and the Replace value. It should
handle optional separators (space, dash, underscore) before
the suffix.
Convert one separator to another
Best for: Switching between underscores, dashes, and slashes across all your layer or style names.Example result:| Before | After |
|---|---|
icon_arrow_left | icon/arrow/left |
color_blue_500 | color/blue/500 |
Copy this prompt
I'm using LintKit's Find & Replace. I want to convert all
[OLD SEPARATOR, e.g. "underscores"] in my layer names to
[NEW SEPARATOR, e.g. "forward slashes"].
Examples:
- [e.g. "icon_arrow_left" should become "icon/arrow/left"]
- [e.g. "color_blue_500" should become "color/blue/500"]
Do I need regex for this, or can I use plain text mode? Give me
the Find and Replace values.
Add a category prefix to all names
Best for: Organizing flat names into Figma’s slash-separated folder structure for the Assets panel or style picker.Example result:| Before | After |
|---|---|
Primary | Button/Primary |
Secondary | Button/Secondary |
Ghost Large | Button/Ghost Large |
Copy this prompt
I'm using LintKit's Find & Replace with regex. I want to add a
prefix to the beginning of all matched layer names, keeping the
existing name intact.
Prefix to add: [e.g. "Button/"]
Examples:
- [e.g. "Primary" should become "Button/Primary"]
- [e.g. "Secondary" should become "Button/Secondary"]
- [e.g. "Ghost Large" should become "Button/Ghost Large"]
Give me the Find pattern (regex) and the Replace pattern. Explain
what $1 means in the replace pattern.
Change an existing prefix to a new one
Best for: Renaming top-level categories across your styles or components without touching the rest of the path.Example result:| Before | After |
|---|---|
Colors/Blue/500 | Color/Blue/500 |
Colors/Brand/Red | Color/Brand/Red |
Copy this prompt
I'm using LintKit's Find & Replace with regex. I want to change
an existing prefix at the beginning of my names to a different one.
Old prefix: [e.g. "Colors/"]
New prefix: [e.g. "Color/"]
Examples:
- [e.g. "Colors/Blue/500" should become "Color/Blue/500"]
- [e.g. "Colors/Brand/Red" should become "Color/Brand/Red"]
Give me the Find pattern (regex) and the Replace value. The
pattern should only match the prefix, leaving everything after
it unchanged.
Swap the order of path segments
Best for: Fixing component names where the segments are in the wrong order (e.g. state before component name).Example result:| Before | After |
|---|---|
Primary/Button | Button/Primary |
Large/Input | Input/Large |
Copy this prompt
I'm using LintKit's Find & Replace with regex. My component
names have slash-separated segments in the wrong order and I
need to rearrange them.
Current format: [e.g. "Primary/Button"]
Desired format: [e.g. "Button/Primary"]
I want to swap [describe the swap, e.g. "the first two segments"].
Examples:
- [e.g. "Primary/Button" should become "Button/Primary"]
- [e.g. "Large/Input" should become "Input/Large"]
Give me the Find pattern (regex) and the Replace pattern using
capture groups. Explain how the capture groups work.
Insert a new level into component paths
Best for: Adding a category grouping (like “Data Entry” or “Feedback”) to the beginning of specific component families.Example result:| Before | After |
|---|---|
Button/Primary | Data Entry/Button/Primary |
Input/Text | Data Entry/Input/Text |
Alert/Error | Feedback/Alert/Error |
Copy this prompt
I'm using LintKit's Find & Replace with regex. I need to add a
category level at the beginning of certain component paths.
Components to categorize: [e.g. "Button", "Input", "Select"]
Category to add: [e.g. "Data Entry"]
Examples:
- [e.g. "Button/Primary" should become "Data Entry/Button/Primary"]
- [e.g. "Input/Text" should become "Data Entry/Input/Text"]
Give me the Find pattern (regex) and the Replace pattern. The
pattern should only match names that start with one of the
listed component names.
Remove a level from component paths
Best for: Flattening overly deep hierarchies by removing an unnecessary middle segment.Example result:| Before | After |
|---|---|
Icons/UI/Arrow Left | Icons/Arrow Left |
Icons/UI/Chevron Down | Icons/Chevron Down |
Copy this prompt
I'm using LintKit's Find & Replace with regex. My component
paths have an unnecessary level I want to remove.
Level to remove: [e.g. "UI/" from paths like "Icons/UI/Arrow Left"]
Examples:
- [e.g. "Icons/UI/Arrow Left" should become "Icons/Arrow Left"]
- [e.g. "Icons/UI/Chevron Down" should become "Icons/Chevron Down"]
Give me the Find pattern (regex) and the Replace value.
Convert style name prefixes to slash folders
Best for: Migrating shorthand style prefixes (likeclr- or typ-) into Figma’s slash-separated folder structure.Example result:| Before | After |
|---|---|
clr-blue-500 | Color/blue-500 |
typ-heading-lg | Typography/heading-lg |
fx-shadow-soft | Effects/shadow-soft |
Copy this prompt
I'm using LintKit's Find & Replace with regex, targeting Styles.
My style names use short prefixes with dashes, and I want to
convert them to slash-separated folder paths.
Prefix mappings:
- [e.g. "clr-" should become "Color/"]
- [e.g. "typ-" should become "Typography/"]
- [e.g. "fx-" should become "Effects/"]
Examples:
- [e.g. "clr-blue-500" should become "Color/blue-500"]
- [e.g. "typ-heading-lg" should become "Typography/heading-lg"]
Give me the Find and Replace values for each prefix. Can I do
this in one pass or do I need multiple find-and-replace operations?
Flatten deeply nested style paths
Best for: Simplifying style names that have accumulated too many levels, likeColors/Brand/Primary/Blue/500.Example result:| Before | After |
|---|---|
Colors/Brand/Primary/Blue/500 | Color/Blue/500 |
Colors/Brand/Primary/Red/600 | Color/Red/600 |
Copy this prompt
I'm using LintKit's Find & Replace with regex, targeting Styles.
My style names have too many levels of nesting and I want to
flatten them by removing intermediate levels.
Current structure: [e.g. "Colors/Brand/Primary/Blue/500"]
Desired structure: [e.g. "Color/Blue/500"]
Levels to remove: [e.g. "Colors/Brand/Primary/" should become "Color/"]
Give me the Find pattern (regex) and the Replace value.
Fix Figma’s auto-generated property names
Best for: Cleaning up component names that contain Figma’sProperty 1=Value syntax.Example result:| Before | After |
|---|---|
Property 1=Primary | Style/Primary |
Type=Large, State=Hover | Large/Hover |
Copy this prompt
I'm using LintKit's Find & Replace with regex, targeting
Components. My component names contain Figma's auto-generated
property syntax like "Property 1=Value".
Examples of what I have:
- [e.g. "Property 1=Primary"]
- [e.g. "Type=Large, State=Hover"]
What I want instead:
- [e.g. "Style/Primary"]
- [e.g. "Large/Hover"]
Give me the Find and Replace patterns for each case.
Build a batch rename template
Best for: Renaming a group of flagged layers using LintKit’s template variables like{parent}, {type}, and {n}.Example result (template: {parent} / Item {nn}):| Parent | Before | After |
|---|---|---|
Card | Frame 47 | Card / Item 01 |
Card | Frame 48 | Card / Item 02 |
Card | Frame 49 | Card / Item 03 |
Copy this prompt
I'm using LintKit's Batch Rename feature (not Find & Replace).
It supports these template variables:
- {name} — current layer name
- {type} — layer type (Frame, Text, Rectangle, etc.)
- {n} — sequential number (1, 2, 3)
- {nn} — zero-padded number (01, 02, 03)
- {nnn} — zero-padded 3 digits (001, 002, 003)
- {parent} — parent layer's name
- {w} — width in pixels
- {h} — height in pixels
- {page} — page name
I want to rename [describe what you're renaming, e.g. "a set of
card layers inside a grid"] to follow this format: [describe
desired format, e.g. "the parent name, then a slash, then a
sequential number like Card / 01, Card / 02"].
Give me the template string using the variables above.
Enforce a naming convention
Best for: Finding layers that violate your team’s casing or formatting rules (Title Case, camelCase, kebab-case, etc.).Example result (enforcing Title Case with slashes):| Before | After |
|---|---|
cardHeader | Card / Header |
card-header | Card / Header |
card_header | Card / Header |
Copy this prompt
I'm using LintKit's Find & Replace with regex. I want to find
all layer names that don't follow my team's naming convention
and fix them.
Our convention is: [describe your convention, e.g. "Title Case
with slashes as separators, like 'Card / Header / Title'"]
Common violations I'm seeing:
- [e.g. "camelCase names like 'cardHeader'"]
- [e.g. "kebab-case names like 'card-header'"]
- [e.g. "names with underscores like 'card_header'"]
Give me the Find patterns to match each violation type, and
suggest the Replace approach. Note that LintKit's regex replace
can't change casing automatically, so let me know if I need to
handle that differently.
Create a custom detection pattern
Best for: Adding your own naming rules to LintKit that flag specific layer names as issues during scans.Example result (flagging placeholder names):| Layer name | Flagged? |
|---|---|
TODO fix this | Yes |
temp button | Yes |
Button Primary | No |
Copy this prompt
I'm using LintKit's custom pattern feature where I can add regex
patterns that flag layer names as naming issues. I want to create
a pattern that flags [describe what to flag].
Examples of names that SHOULD be flagged:
- [e.g. "TODO fix this"]
- [e.g. "temp button"]
- [e.g. "asdf"]
Examples of names that should NOT be flagged:
- [e.g. "Button Primary"]
- [e.g. "Card Header"]
Give me a regex pattern and the flags to use. The pattern will
be used in JavaScript's RegExp constructor.
Replace multiple different names at once
Best for: Batch-fixing abbreviations, old terminology, or inconsistent naming across a file in the fewest passes.Example result:| Before | After |
|---|---|
Btn/Primary | Button/Primary |
Lbl/Name | Label/Name |
Img/Hero | Image/Hero |
Copy this prompt
I'm using LintKit's Find & Replace with regex. I have several
different old names that all need to be replaced.
Replacements needed:
- [e.g. "Btn" should become "Button"]
- [e.g. "Lbl" should become "Label"]
- [e.g. "Img" should become "Image"]
Can I do all of these in one Find & Replace operation, or do I
need separate passes? Give me the most efficient approach.
Tips for better results
- Be specific about your examples. The more before/after examples you include, the more accurate the AI’s regex will be.
- Mention JavaScript regex. LintKit uses JavaScript’s
RegExp— this matters because regex syntax varies between languages. - Ask the AI to explain the pattern. Understanding what each part does helps you verify it’s correct before running it.
- Test with “Find Only” first. LintKit lets you preview matches before applying — always do this.
- One thing at a time. If the AI gives you a complicated pattern, ask if it can be split into simpler steps. Multiple simple passes beat one fragile regex.
See also
- Layer Naming rule — how LintKit detects default names and convention violations
- Batch Rename — LintKit’s built-in batch rename with pattern tokens
- Smart Replace — how LintKit uses library data for color-science matching
- Library Mode — running LintKit inside a library file for library-specific rules