Name things

Skill mikestangdevs/craft-skills/skills/craft/name-things

Skills that make an agent treat code like something you'll have to maintain. Straight, opinionated, small.

Install

npx -y skills add mikestangdevs/craft-skills --skill name-things

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when naming or renaming functions, variables, types, files, or modules — or when a code review keeps stumbling over confusing names. Forces names to reveal intent and role, kills generic names (data, handle, process, manager, util), and aligns vocabulary with the domain. Use when reading code feels harder than it should, when two things have nearly the same name, or before extracting a new function or type that needs a name.

SKILL.md

5.3 KB, as published. Nobody here has run it

Name Things

The failure mode this fixes

Bad names are the cheapest bug to introduce and the most expensive to live with. data, handle, process, manager, info, util, temp, obj — every one is a place where the author gave up on saying what the thing is. Agents are especially prone to this: they generate plausible-but-vague names at scale. The result is code that's technically correct and cognitively exhausting.

This skill makes names carry their weight: a good name tells you what something is and what role it plays, so you don't have to read the implementation to use it.

When to Use This Skill

Naming a new function, variable, type, file, or module
Renaming during a refactor or extraction
A review keeps tripping over what something means
Two identifiers are confusingly similar (user vs userData vs userInfo)
You're about to write a comment to explain a name — the name should do that job

Don't use when: the name is already domain-standard and clear (id, i in a tight loop, well-known abbreviations like url, db). Framework-idiomatic names in their conventional position (req/res in an Express handler, ctx, self/cls) are also exempt — fighting the ecosystem costs more than it clarifies. Don't rename for the sake of renaming.

Instructions

1. Ask what role the thing plays

Names encode role. Before naming, classify:

Boolean → reads as a question/state: isReady, hasAccess, shouldRetry (not flag, status, check). Phrase it positively — isEnabled, not isNotDisabled; negatives double up at the call site (!isNotReady)
Function → verb phrase naming the effect: chargeCard, parseWebhook, evictStaleSessions (not handle, process, doWork)
Collection → plural noun: pendingInvoices (not list, arr, data)
Transformation → name the output, not the act: cents not convert, normalizedEmail not fixEmail

2. Run the ban list

Reject any name that is, or contains, a filler word unless it's genuinely the most precise term:

data, info, value, item, obj, thing, stuff, temp, tmp, handle, process, manage(r), do, util(s), helper, misc, common, base, foo, result, response, res, ret, val, x/y/z (outside math/loops)

For each, ask: "data about what? handle what event? manager of what?" The answer is the real name.

3. Make distinct things distinctly named

If two names differ only by a vague suffix (user / userData / userInfo), they are lying about being different. Either they're the same thing (merge the name) or they play different roles (name the role: requestingUser vs targetUser).

4. Match the domain's words

Use the team's and the product's actual vocabulary. If the business says "subscriber," don't invent "memberAccount." If a CONTEXT.md or glossary exists, names must match it. Mismatched vocabulary is how two engineers build the same thing twice.

5. Length follows scope

Tiny scope (one-line lambda, tight loop) → short is fine.
Wide scope (exported symbol, module-level, long-lived) → spell it out. A name read in 50 places earns its letters.

6. Propagate the rename completely

A rename isn't done until every reference moves with it. Before applying:

Grep the whole repo for the old name and every call site, including strings used for dynamic access (reflection, serialized config, route tables, DB columns, API field names).
Update all of them in one change, or don't rename at all — a half-propagated rename creates two vocabularies for the same thing, which is worse than the original vague name.
For an exported/public symbol, weigh the blast radius: a rename that ripples through consumers may need a deprecation alias rather than a hard cut. When in doubt, propose and confirm before applying.

Output format

When proposing renames, present a table so the human can scan and approve:

| Current      | Proposed            | Why                                   |
|--------------|---------------------|---------------------------------------|
| data         | pendingInvoices     | it's a list of invoices awaiting send |
| handle()     | retryFailedCharge() | it retries; "handle" hides the effect |
| userInfo     | requestingUser      | distinguishes from targetUser         |

Anti-Patterns

Anti-Pattern	Why it defeats the skill
Type-in-the-name (`userObject`, `nameString`, `itemsArray`)	The type system already knows. The name should add meaning, not repeat it.
Comment-as-crutch (`// the list of active users` above `data`)	Move the meaning into the name; delete the comment.
Cute or clever names	`Thanos.snap()` is funny once and confusing forever.
Renaming without grep	A rename you don't propagate creates two vocabularies. Find every call site.

Mental Model

A name is a one-word comment that can never go stale. If you need a comment to explain a name, the name is wrong.