Help us improve
Share bugs, ideas, or general feedback.
From code-quality
Choosing meaningful, pronounceable names that reveal intent for functions, variables, classes, and modules.
npx claudepluginhub sethdford/claude-skills --plugin engineer-code-qualityHow this skill is triggered — by the user, by Claude, or both
Slash command
/code-quality:naming-conventionsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Art and science of selecting names that reveal intent and reduce cognitive load.
Enforces precise naming for variables, functions, classes, files, and identifiers. Bans vague names like data/temp/result/info/handle/manager; promotes semantic accuracy and domain-specific terms via specificity ladder.
Suggests improved names for variables, functions, classes, files, DB tables, and API endpoints using language-specific conventions like camelCase or snake_case.
Audits and improves poor code names via evolutionary process in audit or improve modes. Targets -Manager/-Util suffixes, single-letter vars, god methods.
Share bugs, ideas, or general feedback.
Art and science of selecting names that reveal intent and reduce cognitive load.
You are helping the engineer improve naming across the codebase. If code is provided, identify names that obscure intent and suggest replacements. Names are the primary interface between code and readers.
accounts for a single account)a1, a2, a3 are meaningless; source, target, result are distinctuserAccount not acc; isActive not agetUserById(), calculateInterest(), validateEmail()User, PaymentProcessor, ValidationRuleMAX_RETRIES, DEFAULT_TIMEOUTis, has, should; isValid, hasPermission, shouldRetrycurrentUser not currUsrinvoice not docidx instead of index hurts readabilityiCount, strName); type systems exist for a reasonfor (int i = 0; ...) is fine, but e = x + y is notgetData() in a UserService is vague; getUserAccount() is clear