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).
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
How the pattern works:[_\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.
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
How the pattern works:^ 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).
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.
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.
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.
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.”
Has Icon, Allow Clear, Loading, Full Width, Show Label
If one button uses 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.
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:
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
If the property name is 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.”
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
Simple rule: If the component is mainly used inside another component, it probably should not appear in Replace Component.
Use this when your library is already messy and you need to improve it fast.Fix 1: Rename generic properties first. If you see Property 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.
That is the kind of structure both humans and tools can reason about.
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.
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 (like hero-banner in kebab-case).
This tab walks through how to fix the most common naming problems in your library.
Variant properties are the dropdowns designers see when selecting a variant. Default names like Property 1 give no context about what the property controls.
1
Select the component set in your library file
Click the component set (the purple dashed border) — not an individual variant inside it.
2
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.
3
Rename the property
Click the property name to edit it. Replace generic names with descriptive ones:
Slots and sub-layers are the internal parts of a component that designers can customize. Default names like Frame 12 make it impossible to know which slot does what.
1
Enter editing mode
Double-click into the component to edit its internal layers.
2
Rename layers in the layers panel
Click each layer name in the left sidebar and type a descriptive name that describes the layer’s role.
Internal components (button bases, icon wrappers, layout scaffolds) clutter the assets panel and confuse Replace Component. Three ways to hide them:
1
Option A: Prefix with . or _
Rename the component to .Button Base or _Input Shell. Figma automatically hides dot-prefixed components from library publishing.
2
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.
3
Option C: Move to a private page
Create a page called _Internal or .Helpers and move internal components there. Components on pages with . or _ prefixes are excluded from publishing.
Simple rule: If a component is mainly used inside another component, it probably should not appear in your library’s assets panel.
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.
When different component families use different size labels (Small, sm, S, 16), the library feels inconsistent and tooling can’t match across families.
1
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.
2
Open each component set with a size property
Go through your library and find every component set that has a size variant.
3
Rename each variant value to match
Click the variant value in the Design panel and rename it:
Small → SM
Medium → MD
Large → LG
4
Repeat for every component family
Do this for buttons, inputs, badges, avatars, and every other component with a size property.
This is tedious but one-time. Once standardized, new variants follow the pattern naturally.
When you find components like Card_v2, Card Final, Card fixed, it means the library has accumulated drafts that were never cleaned up.
1
Decide which is the canonical version
Look at which version is most widely used across your files. That’s your canonical component.
2
Archive the old versions
Move old versions to a page called _Archive or _Deprecated. This keeps them accessible but out of the main library.
3
Rename the canonical version
Remove the version suffix: Card_v2 → Card. This is now the single source of truth.
4
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.
5
Delete or hide the archived versions
Once all instances are migrated, hide or delete the old versions so they stop appearing in the assets panel.
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.
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 & Replacefeature 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 usein LintKit's Find & Replace. The suffix should only be removedfrom 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 withFigma's default auto-generated names and I want to replace themwith 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 wordfollowed by a space and number), not names like "Frame Header"or "My Frame".Give me the Find pattern (regex) and the Replace value.
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 removea prefix from the beginning of my layer names. The prefix mightbe 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.
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 removeversion 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 shouldhandle optional separators (space, dash, underscore) beforethe suffix.
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 methe Find and Replace values.
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 aprefix to the beginning of all matched layer names, keeping theexisting 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. Explainwhat $1 means in the replace pattern.
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 changean 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. Thepattern should only match the prefix, leaving everything afterit unchanged.
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 componentnames have slash-separated segments in the wrong order and Ineed 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 usingcapture groups. Explain how the capture groups work.
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 acategory 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. Thepattern should only match names that start with one of thelisted component names.
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 componentpaths 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.
Best for: Migrating shorthand style prefixes (like clr- 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 toconvert 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 dothis in one pass or do I need multiple find-and-replace operations?
Best for: Simplifying style names that have accumulated too many levels, like Colors/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 toflatten 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.
Best for: Cleaning up component names that contain Figma’s Property 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, targetingComponents. My component names contain Figma's auto-generatedproperty 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.
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 nameI want to rename [describe what you're renaming, e.g. "a set ofcard layers inside a grid"] to follow this format: [describedesired format, e.g. "the parent name, then a slash, then asequential number like Card / 01, Card / 02"].Give me the template string using the variables above.
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 findall layer names that don't follow my team's naming conventionand fix them.Our convention is: [describe your convention, e.g. "Title Casewith 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, andsuggest the Replace approach. Note that LintKit's regex replacecan't change casing automatically, so let me know if I need tohandle that differently.
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 regexpatterns that flag layer names as naming issues. I want to createa 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 willbe used in JavaScript's RegExp constructor.
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 severaldifferent 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 Ineed separate passes? Give me the most efficient approach.
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.