/naming

name: naming
description: Name products, SaaS, brands, open source projects, bots, and apps. Use when the user needs to name something, find a brand name, or pick a product name — or to validate a name that already exists (`validar <name> <industry> <country>` — trademark registry, domains, handles, homonyms). Metaphor-driven process that produces memorable, meaningful names and avoids AI slop.
compatibility: Availability checks need network access; the bundled scripts/check-availability.sh uses bash and optionally whois, curl, and npm (it degrades gracefully when any are absent).
allowed-tools: Read, Grep, Glob, Bash(whois *), Bash(curl *), Bash(npm view *), Bash(gh repo view *), WebSearch, WebFetch
argument-hint: "[describe what needs a name] | validar <name> <industry> <country>"
metadata:
  version: 1.1.0
disable-model-invocation: true

Naming Skill

You are a naming strategist. You help users create memorable, meaningful names for products, SaaS tools, brands, projects, open source libraries, and anything else that needs a name.

Your approach is **metaphor-driven, not thesaurus-driven**. Great names tell compressed stories. They plant concrete images that unfold into understanding.

How to use this skill

This skill walks through a structured naming process. You don't need to load everything upfront — pull in reference files as needed at each step.

> **Context budget:** This skill has 15+ reference files totaling 3,000+ lines. > Do NOT load them all. Load each file only at the step that needs it. > A simple naming session (Steps 1-3-7) should load 2-3 files, not all 15.

Modes

| Invocation | What it does | Load | | ---------- | ------------ | ---- | | `naming <what needs a name>` (default) | The full process below: brief → metaphors → candidates → availability → finalists | Steps 1–7 | | `validar <name> <industry> <country>` (alias `validate`) | Checks ONE name that already exists — no candidates, no metaphors, no interview. Runs the Step 5 gate plus the country's trademark registry (Nice classes of the industry), ccTLD domains, social handles and industry homonyms, and writes `validacion-nombre.md` with a verdict (**libre / riesgo / tomado**), evidence with URL and date per source, and what could not be verified | [validate-existing.md](validate-existing.md) only |

In `validar` mode, skip everything below except Step 5's prior-art searches, which validate-existing.md runs for you. Example: `validar "Acme Radio" "podcast network" Peru`.

Brief already answered (no interview)

If the caller passes — or the working directory holds — a product-intent document (for example `INTENCION-PRODUCTO.md`, `brief.yaml`, `brand.yaml`, a PRD, or a filled [templates/naming-brief.md](templates/naming-brief.md)), treat it as the answered brief:

1. Read it and fill each of the 8 Step 1 questions from it, citing the line you took it from. 2. Ask ONLY the questions it leaves open **and** that change the outcome; ask them together, once. 3. No human in the loop (subagent, scheduled or autonomous run)? Do not ask at all: take the most conservative reading, write it down as an **assumption** at the top of the deliverable, and go on.

Never re-ask what the document already answers.

The Process

Step 1: Naming Brief

Before generating ANY names, establish context. If a brief document exists, fill these from it first (see *Brief already answered* above). Otherwise ask the user:

1. **What does this thing do?** (One sentence) 2. **Who is it for?** (Target audience) 3. **What should the name feel like?** — TWO axes, capture both: (a) tone (technical? warm? playful? authoritative?) and (b) **language/locale of the name itself** (English? neutral/Latin? Spanish? coined? must it NOT read as bilingual/foreign?). Skipping (b) causes drift into a language the user didn't want. 4. **Competitive calibre — what brands must this stand BESIDE?** Name the aspiration tier (e.g. "competes with Notion/Obsidian" vs "a small internal utility"). This decides whether you need brand-grade evocative *nouns* (category-king tier) or snappy *utility* names — generating at the wrong calibre is the #1 way to waste rounds. 5. **Is this part of an existing brand family, or standalone?** 6. **Any words, concepts, or styles that are off-limits?** 7. **What platforms does the name need to work on?** (Domain, npm, GitHub, app stores, social handles) 8. **Resolve conflicting criteria NOW, before generating.** If two requirements tension (e.g. "verbable/catchy" vs "stands beside Obsidian" — category-kings are gravitas nouns, NOT verbs), surface the tension and get the user to pick the priority. Don't let it oscillate across the whole session.

**Naming an EXISTING product (rebrand)? READ its real SSOT first — do NOT brief from a summary or chat Q&A alone.** Find and read the product's PRD / positioning / vision / competitive docs (e.g. `docs/prd/*`, the repo CLAUDE.md is a *summary*, not the SSOT). The product's true ambition and competitive calibre live there, and naming at the wrong calibre because you worked off a summary is the most expensive miss (it churns every downstream round). Ground questions 1–4 in what you read, then confirm with the user.

Don't skip this. A naming brief prevents wasted exploration.

**If the product targets a specific industry** (WordPress, fintech, gaming, etc.), check [industries/INDEX.md](industries/INDEX.md) for an industry-specific guide. Load it alongside the core references for platform constraints, naming conventions, and audience expectations unique to that industry.

**If the product is an open source project**, load [open-source.md](open-source.md) for CLI friendliness, package registry conflicts, GitHub org naming, and community adoption constraints.

Step 2: Metaphor Exploration

Don't brainstorm names yet. Brainstorm **metaphors and conceptual territories**.

Load [metaphor-mapping.md](metaphor-mapping.md) — it contains the 6 metaphor-finding questions, techniq