naming（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.

~/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.

Output Contract

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

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.

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

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