> ## 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. # Component & Layer Naming > Best practices for naming components, layers, and variant properties so your library works well with LintKit and your whole team. ## 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 | 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 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 | 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) 1. **Rename generic properties first** — `Property 1` → `Style`, `Property 2` → `Size`, etc. This is the highest-impact change. 2. **Pick one size system** — `XS / SM / MD / LG / XL` across every family 3. **Pick one state system** — `Default / Hover / Focused / Disabled / Error` across every family 4. **Remove version suffixes** — archive old versions, keep one canonical component 5. **Hide internal helpers** — prefix with `_` or `.`, or use "Hide when publishing" 6. **Name slots by role** — `Header`, `Content`, `Footer` instead of `Slot A`, `Area 1` 7. **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. ## 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` | **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. *** ### 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` | **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). *** ### 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` | **How capture groups work:** `^(.+)$` 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-based naming** — template: `{parent} / {type} {n}` | Parent | Before | After | | -------- | --------- | ------------------ | | `Card` | `Frame 1` | `Card / Frame 1` | | `Card` | `Text 3` | `Card / Text 2` | | `Header` | `Group 5` | `Header / Group 1` | **Size-based naming** — template: `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/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: 1. **File** — e.g. `Product Design System` 2. **Page** — e.g. `Data Entry` 3. **Section / frame** — e.g. `Inputs` 4. **Component path** — e.g. `Input/Search` 5. **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. * `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` 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: * `XS`, `SM`, `MD`, `LG`, `XL` This is more stable than raw pixel naming. Do not mix `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 | **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:** | 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` | 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. | Bad | Better | | ------------- | ----------------- | | `Area 1` | `Header` | | `Slot A` | `Content` | | `Frame 12` | `Footer` | | `Section B` | `Leading icon` | | `Custom Area` | `Supporting text` | **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. 1. **Generic property names** — `Property 1`, `Property 2`, `Variant` 2. **Duplicate semantic paths** — two different component sets resolve to the same human meaning 3. **Versioning rot** — `_final`, `_v2`, `_new`, `_old` 4. **Inconsistent casing** — mixing camelCase, kebab-case, Title Case, and UPPERCASE inside the same family 5. **Helper contamination** — internal atoms or fragments mixed with public components 6. **Color-based naming** — `Green Button`, `Blue Badge`, `Red Alert` 7. **Project-management naming** — `Ready for Dev`, `Use This One`, `New`, `Final Final`, initials, emojis, sprint notes 8. **Overloaded `Type`** — same label used for different semantic jobs 9. **Long slash spaghetti** — paths so deep they stop being readable 10. **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. | 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 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 1. Never publish `Property 1`, `Property 2`, or `Variant` as-is 2. Every public component must have a stable semantic path 3. Use one controlled vocabulary for size 4. Use one controlled vocabulary for state 5. Boolean properties must be affirmative and explicit 6. Internal helpers must be hidden from the public library 7. No duplicate semantic paths 8. Do not name by color if the name represents a role 9. Do not use version suffixes as a permanent naming strategy 10. 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 ``` A healthy input family: ``` Data Entry/Input/Search ├── Style = Filled | Outline ├── Size = SM | MD | LG ├── State = Default | Focused | Error | Disabled ├── allowClear = True / False └── showLeadingIcon = True / False ``` 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: 1. **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. 2. **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. 3. **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. Click the component set (the purple dashed border) — not an individual variant inside it. Look for the variant property names listed under the component set name. You'll see names like `Property 1`, `Property 2`, etc. Click the property name to edit it. Replace generic names with descriptive ones: * `Property 1` → `Style` * `Property 2` → `Size` Click each value to rename if needed: * `Variant 1` → `Primary` * `Variant 2` → `Secondary` **Before:** ``` Button component set ├── Property 1 = Primary ├── Property 1 = Secondary ├── Property 2 = Default ├── Property 2 = Hover ``` **After:** ``` 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 like `Property 3` don't communicate what the toggle does. Click the component itself (not the component set) — the one with the purple diamond icon. In the Design panel, look for properties with true/false values. 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:** ``` Property 3 = true/false ``` **After:** ``` 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 like `Frame 12` make it impossible to know which slot does what. Double-click into the component to edit its internal layers. Click each layer name in the left sidebar and type a descriptive name that describes the layer's role. **Before:** ``` Frame 12 Group 4 Rectangle 1 ``` **After:** ``` 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: Rename the component to `.Button Base` or `_Input Shell`. Figma automatically hides dot-prefixed components from library 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. 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. *** ## 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 multiple layers in the layers panel, or press **Cmd/Ctrl+A** to select all layers on the current page. Press **Cmd/Ctrl+R** to open Figma's bulk rename dialog. 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. Review the preview and click **Rename** to apply changes to all selected layers. ### 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](/rules/cleanup#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. 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. Go through your library and find every component set that has a size variant. Click the variant value in the Design panel and rename it: * `Small` → `SM` * `Medium` → `MD` * `Large` → `LG` 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. Look at which version is most widely used across your files. That's your canonical component. Move old versions to a page called `_Archive` or `_Deprecated`. This keeps them accessible but out of the main library. Remove the version suffix: `Card_v2` → `Card`. This is now the single source of truth. If instances of the old version exist in consumer files, use Figma's **Swap component** feature to migrate them to the canonical version. 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](https://claude.ai) or [ChatGPT](https://chatgpt.com) 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` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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 (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` | ```text title="Copy this prompt" theme={null} 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, 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` | ```text title="Copy this prompt" theme={null} 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's `Property 1=Value` syntax. **Example result:** | Before | After | | ------------------------- | --------------- | | `Property 1=Primary` | `Style/Primary` | | `Type=Large, State=Hover` | `Large/Hover` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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 | ```text title="Copy this prompt" theme={null} 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` | ```text title="Copy this prompt" theme={null} 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](/rules/cleanup#layer-naming) — how LintKit detects default names and convention violations * [Batch Rename](/rules/cleanup#batch-rename) — LintKit's built-in batch rename with pattern tokens * [Smart Replace](/features/smart-replace) — how LintKit uses library data for color-science matching * [Library Mode](/features/library-mode) — running LintKit inside a library file for library-specific rules