name-thingslisted

# 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`