Naming

When to Use#

Naming work appears when the user needs a name that other people must understand, remember, say, search, or implement correctly.

Use this for products, brands, features, APIs, packages, files, folders, internal codenames, taxonomy cleanups, and risky renames where bad naming creates confusion, rework, or avoidable collisions.

Architecture#

Memory lives in ~/naming/. If ~/naming/ does not exist, run setup.md. See memory-template.md for structure.

text

~/naming/
├── memory.md      # Stable naming taste, banned patterns, durable constraints
├── briefs.md      # Reusable naming briefs by asset or project
├── winners.md     # Approved names, backups, and rationale
├── collisions.md  # Rejected candidates and collision notes
└── archive/       # Retired names, old briefs, and obsolete language

Quick Reference#

Load the smallest file that removes the current naming uncertainty.

TopicFileSetup guidesetup.mdMemory templatememory-template.mdConstraint-first briefbrief-template.mdCandidate scoring rubricscorecard.mdNaming patterns by surfacesurface-patterns.mdSafe rename protocolrename-playbook.md

Output Contract#

When this skill is active, produce a naming deliverable that is decision-ready, not just a brainstorm dump.

OutputPurposeBrief summaryLock the object, audience, constraints, and success criteriaOption familiesShow structured variation instead of random isolated namesShortlist with scoresExplain why finalists survive the filtersRecommendationPick one winner plus two backupsRisk notesFlag collisions, ambiguity, rollout risk, or missing verification

If the user only asks for ideas, still keep the internal structure. Raw lists without rationale usually create another round of confusion instead of a decision.

Naming Lanes#

First identify which lane the work belongs to. Good names are surface-specific.

LaneOptimize forCommon failureFileProduct or brandMemorability, distinction, room to growSounds clever but says nothingbrief-template.mdFeature or workflowInstant comprehension in UI and docsMarketing language hides the jobsurface-patterns.mdAPI, endpoint, schema, methodConsistency, predictability, low ambiguityMixed verbs, nouns, and tensesurface-patterns.mdPackage, repo, command, file, folderScan speed, exactness, maintainabilityDecorative naming hurts retrievalsurface-patterns.mdInternal codenameFast alignment and low collisionLeaks into public language accidentallyrename-playbook.md

Core Rules#

1. Start with the RALLY brief before generating names#

• Use brief-template.md to lock the asset, audience, lexical guardrails, and why the name matters.
• RALLY stands for Role, Audience, Limits, Lexicon, Yardstick.
• If the brief is vague, do not pretend ideation quality will save it. Ambiguous briefs create attractive but unusable names.

2. Separate utility naming from brand naming#

• Utility surfaces such as features, APIs, files, and commands should bias toward clarity and predictability.
• Brand surfaces can trade a little exactness for recall, story, and distinctiveness, but still need to pass comprehension fast enough for the context.
• Never judge a feature name with the same rubric used for a company name. The lane defines the winning tradeoff.

3. Generate option families, not one flat list#

• Create at least three families with different angles: descriptive, metaphorical, compound, outcome-first, or system-consistent.
• Keep siblings internally coherent so the user can compare strategies, not just individual words.
• A strong family often reveals the right direction even when none of the exact first-pass candidates survive.

4. Run every finalist through the CLASH scorecard#

• Use scorecard.md before recommending a winner.
• CLASH stands for Clarity, Load, Adjacency, Search collision, Harm.
• A name is not done because it sounds good. It must also survive spelling, pronunciation, ambiguity, namespace overlap, and negative connotations.

5. Match the surrounding system before optimizing the single name#

• Check product architecture, menu hierarchy, endpoint family, file layout, or taxonomy before choosing the local label.
• A slightly less exciting name is better if it makes the whole system easier to scan and predict.
• Prefer consistency across sibling names over isolated cleverness.

6. Recommend one winner, two backups, and the deciding reason#

• Do not leave the user with ten equally weighted options unless they explicitly asked for open exploration.
• State why the winner wins in this context: better comprehension, lower collision risk, stronger recall, better family fit, or safer rollout.
• If legal, trademark, domain, or live namespace verification still matters, say that explicitly instead of implying clearance.

7. Treat renames as migrations, not word swaps#

• A rename can break routes, docs, API clients, analytics, onboarding, and mental models.
• Use rename-playbook.md whenever the job touches live systems or published language.
• Always map what changes, what aliases are needed, and what must remain backward-compatible during transition.

8. Learn durable naming taste, not one-off opinions#

• Store recurring constraints in local memory: words the user avoids, tone preferences, naming style, and family patterns that keep winning.
• Do not store every brainstorm. Store only reusable signals that improve future naming quality.
• If the user rejects multiple options for the same reason, promote that reason into a durable rule.

Common Traps#

TrapWhy It FailsBetter MoveBrainstorming before defining the objectDifferent people optimize for different jobsLock the brief firstPicking the cleverest name in the roomClever often decays into explanation debtScore for clarity and retrieval firstMixing external and internal namesTeams start leaking placeholder languageDecide what is public, internal, and transitionalRenaming one node without the systemAdjacent labels become inconsistent and confusingAudit sibling names before final choiceUsing invented spelling to look distinctiveSearch, pronunciation, and trust all get worsePrefer real words unless the lane truly justifies inventionConfusing category fit with legal clearanceSimilarity risk stays hiddenMark live trademark or namespace verification as still requiredLeaving the decision at "here are some ideas"The user still has no recommendationPick a winner and defend it

Security & Privacy#

Data that stays local:

• Naming briefs, durable constraints, approved names, and rejected patterns in ~/naming/

This skill does NOT:

• Claim trademark, domain, or regulatory clearance without explicit live verification
• Make undeclared network requests
• Register names, buy domains, or mutate production systems by itself
• Rename live assets without an explicit migration plan

If the user wants live checks for search results, domains, trademarks, package registries, or repository availability, say what is being checked before using external services.

Related Skills#

Install with clawhub install <slug> if user confirms:

• branding — define positioning and voice before committing to a public-facing name
• product — shape product framing and packaging around the chosen name
• product-manager — align feature and workflow names with user language and roadmap context
• strategy — evaluate category, portfolio, and market tradeoffs behind naming decisions
• api — keep API naming, endpoint language, and auth terminology consistent

Feedback#

• If useful: clawhub star naming
• Stay updated: clawhub sync