$ loading_
Name code by domain meaning to improve clarity and team alignment.
This skill appears to be prompt/documentation-only, with no secrets, no network egress, and no code execution; overall risk is low. The repository is open source and auditable, but low community adoption and unknown maintenance status warrant some supply-chain caution.
No secrets, tokens, or environment variables are required, and there are no signs of credential collection, forwarding, or misuse.
No remote host is declared, and the content is purely a naming guideline with no user-data transmission path.
Objective checks indicate prompt-only behavior, with no evidence of spawning processes, executing code, or invoking system capabilities.
There is no described access to local files, project code, or other resources; the artifact is essentially static guidance.
The source is an auditable open-source GitHub repository, but the license is undeclared, community adoption is 0 stars, and maintenance status is unknown, so supply-chain confidence is limited.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "Domain-Focused Naming" skill from askskill: 1. Download https://raw.githubusercontent.com/obra/clank/main/skills/coding/naming-by-domain/SKILL.md 2. Save it as ~/.claude/skills/naming-by-domain/SKILL.md 3. Reload skills and tell me it's ready
Review the following order-system code and rename classes, functions, and variables using domain-focused names. Avoid implementation details, technical abbreviations, or legacy names, and explain the reason for each rename: [paste code]
A list of improved domain-focused naming suggestions with explanations for each change.
Our team uses inconsistent names across payment, refund, and settlement code. Create a concise naming guide based on domain-focused naming principles, including recommended patterns, anti-patterns, and example comparisons.
A practical naming guideline that aligns code terminology with the business domain.
Review this set of API endpoint names, field names, and parameter names. Determine whether they reflect business meaning rather than technical implementation; if not, suggest better domain-focused alternatives: [paste API definition]
An API naming review highlighting issues and proposing clearer domain-driven alternatives.
Names documenting implementation or history create confusion. "NewUserAPI" doesn't tell what it does. "ZodValidator" exposes internals.
Core principle: Names tell what code does in the domain, not how it's built or what it replaced.
Violating the letter of this rule is violating the spirit of naming.
Use for:
Use ESPECIALLY when:
Names expose WHAT, not HOW.
<Bad> ```typescript class ZodValidator { } // Exposes Zod library class MCPToolWrapper { } // Exposes MCP protocol class JSONConfigParser { } // Exposes JSON format ``` </Bad> <Good> ```typescript class Validator { } // What it does class RemoteTool { } // What it represents class ConfigReader { } // What it does ``` </Good>Code exists in present. Don't reference past or transitions.
<Bad> ```typescript class NewAPI { } // When does it stop being "new"? class LegacyHandler { } // Calls it legacy but it's running class ImprovedParser { } // Improved from what? class UnifiedService { } // What was unified? class EnhancedValidator { } // Enhanced how? ``` </Bad> <Good> ```typescript class API { } // What it is now class Handler { } // What it does now class Parser { } // What it does now class Service { } // What it is now class Validator { } // What it does now ``` </Good>Patterns are implementation details. Most don't help understanding.
<Bad> ```typescript class ToolFactory { } // "Factory" adds nothing class ServiceBuilder { } // "Builder" adds nothing class ManagerSingleton { } // "Singleton" adds nothing ``` </Bad> <Good> ```typescript class Tool { } // Clear without pattern class Service { } // Clear without pattern class Registry { } // Clear without pattern// OK when pattern IS the purpose class EventEmitter { } // Observer pattern IS what it does class CommandQueue { } // Queue pattern IS what it does
</Good>
### Names Tell Domain Stories
Good names form sentences about business logic.
<Good>
```typescript
// Reads like domain language
user.authenticate()
order.calculateTotal()
payment.process()
// Not
user.executeAuthenticationStrategy()
order.runTotalCalculationAlgorithm()
payment.invokeProcessingWorkflow()
| Bad Pattern | Why Bad | Good Alternative |
|---|---|---|
ZodValidator | Exposes implementation | Validator |
MCPToolWrapper | Exposes protocol | RemoteTool |
NewUserAPI | Temporal reference | UserAPI |
ImprovedParser | References history | Parser |
ToolFactory | Pattern name noise | Tool or createTool() |
AbstractToolInterface | Redundant qualifiers | Tool |
executeToolWithValidation() | Implementation in name | execute() |
Rule: Never document old behavior or the change in names.
<Bad> ```typescript // During refactoring class NewAuthService { } // References the change class ImprovedValidator { } // References improvement class UnifiedAPIClient { } // References unification ``` </Bad> <Good> ```typescript // During refactoring class AuthService { } // What it is class Validator { } // What it does class APIClient { } // What it is ``` </Good>…
Compare 2-3 approaches before execution to choose a stronger solution.
Write evergreen comments focused on what and why, not historical context.
Search past Claude Code chats to recover facts, decisions, and context.
Design systems by hiding implementation details behind domain-level interfaces.
Plan with pseudocode first, refine approaches, then translate into working code.
Helps developers keep class abstractions cohesive and free of unrelated responsibilities.
Extract and maintain a domain glossary with consistent terms and ambiguity checks.
Generate multilingual code identifier names from domain concepts.
Choose clear, accurate variable names that improve code readability and maintenance.
Improve code and product names step by step through a three-phase process.
Helps developers write code comments explaining intent, rationale, and key tradeoffs.
Improve code clarity and maintainability by assigning each variable one purpose.