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 1 that were never renamed
- Components named by color or appearance instead of purpose
- Inconsistent size or state labels across families
Type or Variant meaning different things in different components
- Internal helpers published alongside real components
- Duplicate semantic paths
- Version suffixes like
_final or _v2 baked into published names
What good naming looks like
Name by purpose, not appearance
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: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 to Style, Size, State, etc.
- Unrenamed
Variant or Type — rename to describe what the axis actually controls
Frame 104, Component 7 — replace with semantic names
Button_final_v2 — archive the old version, keep one canonical component
Blue Button, Green Alert — use role names like Primary and Success
Slot A, Area 1 — use role names like Header, Content, Footer
Comparison examples
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 / XL across every family
- Pick one state system —
Default / Hover / Focused / Disabled / Error across 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, Footer instead of Slot 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, not Hide 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.
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/Primary
Input/Search
Alert/Success
Implementation naming describes visual traits, technical leftovers, or temporary status:
Blue Button
Frame 104
Property 1=Primary
Button_Final_v2
Name for intent, not appearance. If your brand color changes from blue to red, 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:
Actions
Data Entry
Navigation
Data Display
Feedback
Overlays
Layout
Foundations or Primitives
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.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
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.
Size vocabulary
Use T-shirt sizes as the default:This is more stable than raw pixel naming.
Do not mix Small, sm, S, 16, and Regular as if they are interchangeable.Use relative size meaning, not raw build values.
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:
Boolean naming
Boolean properties should read like a clear yes/no question. Use affirmative prefixes: is, has, show.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.”
Slots and sub-parts
Complex components often expose slots, instance swaps, or nested subcomponents. Those names must still be semantic.Name the role, not the coordinate. If a user is replacing content in a modal, 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
Simple rule: If the component is mainly used inside another component, it probably should not appear in Replace Component.
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.
- 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.
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 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.
Non-negotiable rules
- Never publish
Property 1, Property 2, or Variant as-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:A healthy input family: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.
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 (like hero-banner in kebab-case).
This tab walks through how to fix the most common naming problems in your library.
Fixing component variant properties
Variant properties are the dropdowns designers see when selecting a variant. Default names like Property 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 → Style
Property 2 → Size
Rename the values too
Click each value to rename if needed:
Variant 1 → Primary
Variant 2 → Secondary
Before:After:
Fixing component boolean properties
Boolean properties control toggles like “show icon” or “is loading.” Default names like Property 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.
Find the boolean properties
In the Design panel, look for properties with true/false values.
Rename the property
Click the property name to edit it. Use an affirmative prefix:
Property 3 → Show icon
Property 4 → Is loading
The value is automatically true or false — you only need to rename the property itself.Before:After:
Fixing slot and sub-layer names
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.Enter editing mode
Double-click into the component to edit its internal layers.
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.
Before:After:
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.
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.
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.
Open the Rename dialog
Press Cmd/Ctrl+R to open Figma’s bulk rename dialog.
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.
Apply the rename
Review the preview and click Rename to apply changes to all selected layers.
Useful find-and-replace patterns
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 → SM
Medium → MD
Large → LG
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.
Handling version suffixes
When you find components like Card_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.
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.
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:
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:
Remove a prefix from layer names
Best for: Stripping WIP, DRAFT, DELETE, OLD, or any temporary markers before handoff or publishing.Example result:
Clean up version or status suffixes
Best for: Removing _v2, _final, NEW, old, and other naming debt accumulated over time.Example result:
Convert one separator to another
Best for: Switching between underscores, dashes, and slashes across all your layer or style names.Example result:
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:
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:
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:
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:
Remove a level from component paths
Best for: Flattening overly deep hierarchies by removing an unnecessary middle segment.Example result:
Convert style name prefixes to slash folders
Best for: Migrating shorthand style prefixes (like clr- or typ-) into Figma’s slash-separated folder structure.Example result:
Flatten deeply nested style paths
Best for: Simplifying style names that have accumulated too many levels, like Colors/Brand/Primary/Blue/500.Example result:
Fix Figma’s auto-generated property names
Best for: Cleaning up component names that contain Figma’s Property 1=Value syntax.Example result:
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}):
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):
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):
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:
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.