A 400-frame Figma file named "Frame 247," "Group 12," and "Untitled" is a file only its author can navigate, and barely. By 2026 you can clean it in fifteen minutes with Magician for Figma, Figma's AI rename, and a Claude-authored naming convention, and re-index a whole component library so that not just humans but AI agents - Storybook MCP, Figma Code Connect - can actually find what they need. The catch, and the reason this is an L2 lesson and not a one-click trick, is that AI auto-naming will confidently name a "delete" button "submit" and tag a destructive component as a routine one, so the speed is real but every name has to be verified against a convention you authored. The artifact is a renamed file, a naming-convention doc, and an indexed component library with descriptions and tags built so machines can read it.

The File Only Its Author Can Read

Start with the file every designer has inherited or created. Four hundred frames, named by Figma's defaults: "Frame 247," "Group 12," "Rectangle 9," "Untitled," and a hundred more like them. The original designer could navigate it by spatial memory, knowing the checkout flow was "over there on the right." Then they left, or six months passed, and now nobody can find anything. An engineer trying to map a component via Code Connect opens the file and sees "Group 88" where they expected "Button/Primary." A new designer spends an hour just learning the geography. The file is technically complete and functionally illegible.

This illegibility used to be a chore you deferred forever because renaming 400 frames by hand was a full day of mind-numbing work nobody would fund. AI changed the economics: the fifteen-minute version is now real. But the fifteen-minute version has a failure mode that the all-day manual version did not, which is that an AI renamer works by inferring intent from appearance, and appearance is exactly where it gets the high-stakes cases wrong. So the lesson is not "press the rename button." It is "press the rename button, then verify the names the way only someone who knows what the components actually do can."

This is the L2 discipline applied to design ops. The tools supply the speed: hundreds of names and tags in minutes. You supply the verification and the convention, because a name is a promise about what a thing does, and an AI inferring that promise from pixels will break it precisely on the components where a broken promise costs the most.

The Three Tools and Their Distinct Jobs

Three tools do three different parts of this job, and using each for its actual strength is half the skill.

Figma's AI rename is the bulk workhorse. Point it at a selection of frames or layers and it renames them based on content, turning "Frame 247" into "Login Screen" and "Rectangle 9" into "Card Background." It is fast and it is right most of the time on low-stakes, descriptive naming. Use it for the volume pass on the 400 frames, where being approximately right on 380 of them in two minutes is a massive win over manual renaming.

Magician for Figma adds AI-assisted naming, content, and tagging with a bit more flexibility, and is useful for component-level work and for generating descriptions and tags rather than just names. Where Figma's rename gives you a label, Magician helps you produce the richer metadata - a description of what the component is for, tags for how it is categorized - that an index needs.

Claude does the job neither of the in-tool tools can: it authors the naming convention itself. You do not want each tool inventing its own naming pattern; you want one convention, written down, that every name conforms to. Claude is excellent at taking your requirements ("we use Component/Variant/State, components are PascalCase, states are lowercase") and producing a clear, documented convention plus examples and edge cases. The convention is the thing that makes the renamed file coherent rather than just differently-messy, and it is the thing the in-tool AI does not give you.

Why the Convention Comes First, Not the Renaming

The sequencing is the most important methodological point in the lesson, and it is counterintuitive: you author the naming convention before you run any auto-rename, not after. The temptation is to rename everything fast and tidy up the pattern later, but that is backwards, because without a convention the AI renamer invents its own implicit pattern, and you end up with 400 names that are individually plausible and collectively inconsistent - "Login Screen," "screen-signup," "Onboarding_3," "forgot password page," all describing the same kind of thing four different ways.

So first, with Claude's help, you write the convention: the structure (Component/Variant/State), the casing, the rules for how variants and states are expressed, how screens versus components versus primitives are distinguished, and a set of worked examples. This document is itself one of the three artifacts, and it is the one with the longest life, because it governs not just this cleanup but every name anyone adds to the system from now on. Then, with the convention in hand, you run the auto-rename and verify each name against the written rule rather than against your gut, which makes the verification fast and objective: a name either conforms to the convention or it does not.

A name is a promise about what a thing does. Auto-naming makes 400 promises in two minutes, and inference from pixels breaks the promise exactly where it matters most. The convention is the standard you verify every promise against.

The Failure Mode: When the Renamer Names a Delete Button "Submit"

Here is why this is an L2 lesson and not a productivity tip. AI auto-naming infers a thing's purpose from its appearance, and for high-stakes components that inference is exactly where it fails. A destructive "delete account" button and a routine "submit" button can look nearly identical - same shape, same size, sometimes the renamer cannot read the label clearly or weighs the visual pattern over the text - and the renamer will confidently name the destructive one "submit" or "primary action." A toggle that controls a dangerous setting gets tagged like any other toggle. A component that is actually a one-off variant gets named as if it were the canonical version.

These errors are dangerous in a way that a misnamed "Card Background" is not, because the name is what other systems and people trust. An engineer reading Code Connect sees "submit" and wires the destructive action up as a routine one. An AI agent generating a prototype from the library reads the tag and uses the dangerous component in a safe context. The misname propagates with the authority of a label. So the verification rule is stratified by stakes: skim the low-stakes descriptive names quickly, because being approximately right is fine, and verify every name and tag on a destructive, security-relevant, or canonical-versus-variant component with care, because there a wrong name is a wrong promise that other systems will act on. This is the L1 frequency-versus-stakes model applied to naming: spend your verification where being wrong is expensive.

Indexing for Machines: Component/Variant/State, Descriptions, and Tags

Renaming the 400-frame file is the warm-up. The real prize is re-indexing the component library so that AI agents can find and use components correctly, because in 2026 the consumers of your library are no longer only human. The Storybook MCP server and Figma Code Connect let AI agents read your component library to generate prototypes and code, and an agent can only use a component it can find and understand. An unindexed library is invisible to them; a well-indexed one is a capability.

Indexing means three things layered on each component. First, a consistent structured name following Component/Variant/State, so "Button/Primary/Disabled" and "Button/Secondary/Hover" are predictable and an agent can reason about the variant space. Second, a description: a plain-language statement of what the component is for and when to use it, because a name tells an agent the component exists but a description tells it whether this is the right one ("Primary button for the single most important action on a screen; do not use more than one per screen"). Third, tags: the categorical metadata that lets an agent filter and find ("form", "destructive", "navigation"). The description and the destructive tag are the parts that prevent an agent from using your delete button as a save button, which is the same high-stakes failure as the misname, now at the library level. A library indexed this way is readable by Storybook MCP and Code Connect, which means an agent prompted to build a screen can pull the right real components instead of inventing ghost ones.

Why Machine-Readable Indexing Is the Real Payoff

It is worth being explicit about why the indexing, not the renaming, is the high-value half of this lesson. A clean file helps humans navigate, which is nice. A machine-readable indexed library changes what the rest of your AI toolchain can do, which is transformational. Every other AI prototyping move in this level - v0 translating a screen, Lovable building an app, an agent assembling components - is only as good as the library it reads from. If the library is "Group 88" with no descriptions and no tags, the agent invents components and drifts off-system, recreating the ghost-component problem from the First Draft lesson at the speed of automation. If the library is indexed with structured names, descriptions, and tags, the agent reads your real components, understands their intended use, and respects the destructive-versus-safe distinction.

So the indexed library is the foundation that makes the rest of the AI design stack safe to use. It is the difference between AI agents that amplify your design system and AI agents that erode it. Spending the fifteen minutes to rename and the additional time to index is not design-ops housekeeping; it is the prerequisite for every downstream AI tool to read your system as truth instead of guessing at it. That is why this lesson sits where it does: it is the infrastructure the prototyping lessons quietly depend on.

Keeping the Index From Rotting: The Publish Gate

A library indexed once and then left alone rots, because components keep getting added, and every component added without a conforming name, a description, and tags is a fresh patch of invisibility for the agents that read the library. The fifteen-minute cleanup is a one-time event; keeping the library AI-ready is a standing property, and a standing property needs governance, not heroics. The mechanism is a publish gate: a rule that no component enters the library without a Component/Variant/State name that conforms to the convention, a plain-language description, and tags including a destructive or sensitive flag where it applies. Enforce it with a publish checklist or a lint that blocks non-conforming additions, so the index cannot silently degrade one un-described component at a time.

Pair the gate with a periodic audit, because gates leak and legacy debt accumulates. Run Magician or a Claude pass across the library on a cadence, flagging every component missing a description or a tag, and prioritize the destructive components for human verification, because a destructive component that slipped in untagged is the highest-stakes gap an agent could hit. Synchronize the audit with the library's MCP and Code Connect exposure, so that no un-indexed addition is ever readable by an agent before it has been brought up to standard. Track a single metric - the rate of un-indexed components in the library - and drive it toward zero, treating any rise as a signal that the gate is being bypassed.

This governance is what converts indexing from a cleanup that decays into a guarantee that holds. The convention is the contract every component must meet; the publish gate prevents new debt; the audit catches the debt that slips through; and the metric makes the library's health visible. Without this, a team does the fifteen-minute cleanup, feels accomplished, and watches the library drift back into "Group 88" over the next two quarters as new work lands un-indexed, recreating exactly the agent-guessing problem the cleanup was meant to solve. With it, the library stays a reliable source of truth for every human and agent that reads it, which is the only state in which the rest of the AI design stack can safely stand on it. The cleanup is the visible win; the gate is the invisible discipline that makes the win last.

One subtlety raises the bar specifically because agents, not just humans, now consume the library. A human reading a component brings spatial memory, tribal knowledge, and an instinctive flinch at a misused delete button, so they can compensate for a thin description or a missing tag. An agent has none of that; it has only what the index makes explicit. So when agents are primary consumers, the descriptions must be literal and unambiguous rather than designer shorthand, the tags must be complete enough to filter on, and the destructive and sensitive flags become non-negotiable, because there is no human judgment downstream to catch an omission. In effect the index becomes the agent's entire model of the system, and any gap in the index is a gap in the agent's understanding, which is why an agent-readable library is held to a stricter standard than one read only by people who can fill the gaps from memory.

Putting It to Work This Week

Take your messiest real file and your component library and run the full pattern. First, with Claude, author the naming convention: Component/Variant/State structure, casing rules, screen-versus-component-versus-primitive distinctions, and worked examples, and save it as a living doc. Second, run Figma's AI rename for the bulk pass on the file and use Magician for component descriptions and tags, then verify every name against the written convention, skimming low-stakes descriptive names and carefully checking every destructive, security-relevant, or canonical component. Third, index the component library with structured names, plain-language descriptions, and categorical tags, paying special attention to the destructive tag, so Storybook MCP and Code Connect can read it.

You will know the practice has landed when an engineer opens your file and finds "Button/Primary" where they expected it, and when an AI agent prompted to build a screen pulls your real components with the right intended use instead of inventing ghosts. That second outcome is the one that compounds: a properly indexed library makes every AI tool downstream more accurate and more on-system, every single time it reads from your library. The auto-namers give you the speed to make a 400-frame file legible in fifteen minutes. The convention and the verification are what make the names true, and a library of true names is the foundation the rest of your AI workflow stands on.

Key Takeaways

• AI auto-naming makes a 400-frame file legible in fifteen minutes, but it infers a thing's purpose from appearance and breaks that inference exactly on high-stakes components, confidently naming a "delete" button "submit." The speed is real; every name is a promise that must be verified.
• Use three tools for three jobs: Figma's AI rename for the bulk volume pass, Magician for Figma for component descriptions and tags, and Claude to author the naming convention the in-tool tools cannot give you.
• Author the convention first, before any auto-rename. Without it the renamer invents its own implicit pattern and you get 400 names that are individually plausible and collectively inconsistent. With it, verification becomes fast and objective: a name either conforms or it does not.
• Stratify verification by stakes (the L1 frequency-versus-stakes model): skim low-stakes descriptive names, and carefully verify every name and tag on destructive, security-relevant, or canonical-versus-variant components, because there a wrong name is a wrong promise other systems will act on.
• Index the component library in three layers so machines can read it: structured Component/Variant/State names, plain-language descriptions of intended use, and categorical tags (including the destructive tag), so Storybook MCP and Figma Code Connect agents can find and correctly use real components instead of inventing ghosts.
• The machine-readable index, not the clean file, is the real payoff: it is the foundation that makes every downstream AI tool (v0, Lovable, component-assembling agents) read your system as truth instead of guessing, the difference between AI that amplifies your design system and AI that erodes it.