Naming Convention
Define predictable, searchable names for components, tokens, files, and assets before the design system sprawls.
Overview
Naming Convention is an agent skill most often used in Build (also Ship, Operate) that establishes clear naming rules and examples for design components, tokens, files, and assets.
Install
npx skills add https://github.com/owl-listener/designer-skills --skill naming-conventionWhat is this skill?
- Five principles: predictable, consistent, scalable, scannable, unambiguous
- Pattern templates for components, tokens, files, design pages, code, and assets
- Maps Figma PascalCase components to kebab-case CSS and camelCase React props
- Calls out pitfalls like mystery abbreviations and appearance-based names
- Recommends a single reference page plus automated name linting
- 5 naming principles
- 6 pattern families (components, tokens, files, design files, code, assets)
Adoption & trust: 578 installs on skills.sh; 1.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your design system has inconsistent component, token, and file names that are hard to search and impossible for agents or new teammates to predict.
Who is it for?
Solo builders or tiny teams standing up or standardizing a design system before heavy UI implementation.
Skip if: Projects with no shared components or tokens where ad-hoc filenames are fine, or teams that already enforce naming via a locked external design-system package.
When should I use this skill?
Establishing or refactoring naming rules for design elements, components, tokens, files, and exported assets.
What do I get? / Deliverables
You get documented patterns for components, tokens, files, and code naming plus linting and critique habits so new assets stay aligned with the system.
- Documented naming patterns per asset type
- Reference page rules and linting recommendations
- Critique checklist for new names
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Naming rules are authored when the UI foundation is built and reused whenever new screens or tokens ship. Frontend and design-system work is where component paths, token keys, and asset filenames must stay consistent across Figma and code.
Where it fits
Draft component and token path patterns before the first shared Button and Card land in the repo.
Check new screen exports against file and asset naming rules during pre-release UI review.
Rename ambiguous tokens and icons after a rebrand without breaking semantic aliases.
How it compares
Use for human-readable naming policy across Figma and code—not as a token value generator or component library scaffolder.
Common Questions / FAQ
Who is naming-convention for?
Indie builders and designers shipping SaaS, mobile, or extension UIs who need one repeatable naming scheme for tokens, components, and assets.
When should I use naming-convention?
During Build when defining the design system, during Ship when reviewing new components before release, and during Operate when renaming or extending tokens without breaking searchability.
Is naming-convention safe to install?
It is documentation-style guidance with no built-in shell or network access; review the Security Audits panel on this Prism page before installing any skill from the catalog.
Workflow Chain
Then invoke: design token
SKILL.md
READMESKILL.md - Naming Convention
# Naming Convention You are an expert in creating clear, scalable naming systems for design assets, components, and tokens. ## What You Do You establish naming conventions that make design systems predictable, searchable, and maintainable. ## Principles 1. Predictable 2. Consistent 3. Scalable 4. Scannable 5. Unambiguous ## Patterns - **Components**: [category]/[name]/[variant]/[state] - **Tokens**: {category}-{property}-{concept}-{variant}-{state} - **Files**: [type]-[name]-[variant].[ext] - **Design files**: Numbered + descriptive pages, PascalCase components - **Code**: kebab-case CSS, PascalCase React, camelCase props - **Assets**: icon-[name]-[size], illust-[scene]-[variant] ## Common Pitfalls - Abbreviations only the author understands - Inconsistent separators - Names based on visual properties instead of purpose ## Best Practices - Document rules in a single reference page - Automate name linting - Use prefixes for sorting and grouping - Review names in team critiques