/domain-name

name: domain-name
description: "Use this skill when the user needs to name a product or company and find a domain for it. Also use when the user says 'name my product,' 'what should I call it,' 'help me pick a domain,' 'is this a good name,' 'find me a domain,' 'my domain is taken,' 'check if this name is available,' or pastes a list of candidate names for an opinion. Scores names against ten rules, then verifies domain availability with DNS and RDAP. Do NOT use for buying a domain or pointing DNS at your host once the name is chosen (use deploy), for visual brand identity such as colors, logos, or typography (use brand-identity-generator), for positioning and messaging (use niche-advantage), or for writing headlines and page copy (use copywriting)."
metadata:
  version: 1.0.1

Naming a product and getting the domain

Naming fails in two different ways, and they need different work. A name can be a bad name, or it can be a good name you cannot have. Judge the concept first, then test availability. Running availability checks on a weak shortlist wastes the founder's time on names they should not want.

Optimise in this order

great concept  →  great name  →  acceptable domain

**Never the reverse.** The failure mode is subtle and almost automatic: one pattern starts returning free domains, so you generate more of that pattern, and within two rounds availability is choosing the concept. You will not notice it happening. The symptom is a candidate list where most names share a word or a shape.

A great name with an acceptable domain beats a mediocre name with a pristine one:

• `Foothold` → `getfoothold.com` — **works.** The name is doing the work.
• `Social Engagement Automation` → `socialengagementautomation.com` — **still mediocre.**

A perfect domain cannot rescue a dead name.

So when a strong name's exact domain is gone, do not discard the name. Try the variants in the rule 10 ladder first. Discard a name for being *weak*, never for being *taken*.

Work in three phases. Do not skip ahead to phase 3 — a founder who picks from an unrefined list picks the first name they recognise, which is usually the most generic one.

**Read `references/scorecard.md` before scoring anything.** It holds the ten rules, the test for each, and worked examples.

---

Phase 1 — Generate the initial list

No availability checks yet. Domains are cheap to check and expensive to get attached to.

Step 1: Get the raw material

Ask for whatever is missing, in one message:

1. **Every distinct job the product does. Number them. Do not compress to one sentence.** A three-job product described in one sentence loses two jobs, and whichever job survives becomes the entire naming territory by accident. 2. **What unifies those jobs.** If the product does find → join → publish, the unifying idea is working a defined set of people over time. **The unifying idea is the naming territory, not any single job.** 3. **The outcome the customer gets.** This matters more than the features. `Traction` works because it names what an early-stage product wants. 4. Who it is for. 5. Any word they already like, or any they have ruled out. 6. Whether `.com` is a hard requirement.

If `ABOUT-ME.md` or `MY-ICP.md` exist in the project, read them first and ask only for what they do not answer.

Step 2: Build word pools

Write out the pools before you write any names. Names invented directly tend to cluster around one idea.

**First, one pool per job, plus a unifying pool.** This step is what stops a multi-job product from being named after whichever job you thought about first.

| Pool | Contains | Example — a tool that plans your meals, builds the list, and orders the food | |---|---|---| | Job 1 | Vocabulary for the first job | plan, menu, spread, course | | Job 2 | Vocabulary for the second job | list, tally, cart, basket | | Job 3 | Vocabulary for the third job | order, deliver, stock, fill | | **Unifying** | **Words covering every job at once** | **pantry, larder, table, kitchen** |

**The name usually comes from the unifying pool.** A journalist's *beat* is the people they cover, the conversations they follow, and the stories they publish — one word for three jobs.

Then cut across those with the lexical pools:

| Pool | Contains | Example for a habit tracker | |---|---|---| | Outcome | What the customer ends up with | streak, momentum, traction, foothold | | Object | Concrete things in the domain | ledger, anchor, compass, thread | | Action | What the user does | tally, mark, log, keep | | Metaphor | One conceptual leap away | ratchet, flywheel, cairn, tide |

Before you write a single name, check that some word in your pools touches **every** job. If every word serves one job, stop and rebuild the pools. That is the most common way this skill fails, and everything downstream inherits the error.

Step 3: Produce 20-30 candidates

Cover all five kinds deliberately. Do not let one kind dominate — each fails differently, and a list of one kind inherits that kind's weakness.

| Kind | What it is | Examples | |---|---|---| | **Adjacent concept** | An ordinary word one step from the product. Not descriptive, not a riddle. | Stripe, Notion, Linear, Buffer | | **Plain compound** | Two real words naming the thing you get | Basecamp, Mailchimp, Dropbox | | Outcome word | Names what the customer ends up with | Traction, Foothold | | **Coined** | Invented, but spellable on first hearing | Typefully, Taplio, Calendly | | Metaphor | One conceptual leap | Buffer, for scheduling |

Generate the obvious name first, and check it before you reach

**Before any other kind, build the plain compounds from the product's own nouns** — the words its landing page already repeats — and check those domains immediately.

Take the noun for who it serves, the noun for what it hands them, and put them together. Then do it again with the next pair. Produce a dozen of these before you generate anything clever.