/domain-name

name: domain-name
description: "Use this skill when the founder needs to name a product or company and find a domain: 'name my product,' 'what should I call it,' 'help me pick a domain,' 'is this a good name,' 'my domain is taken,' 'check if this name is available,' or a pasted list of candidate names. Scores names against ten rules, then checks domain availability with DNS and RDAP. Not for pointing DNS at a host once the name is chosen (use go-live) or for writing page copy (use landing-page)."
metadata:
  version: 1.0.0

Naming a product and getting the domain

A name can fail in two ways: it is a bad name, or it is a good name you cannot have. Judge the concept first. Test availability second.

Optimize in this order

great concept  →  great name  →  acceptable domain

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

A great name with an acceptable domain beats a mediocre name with a perfect one. `Foothold` on `getfoothold.com` works. `socialengagementautomation.com` is still a dead name. When a strong name's exact domain is gone, try other suffixes in the acceptable set and the `get`/`use` + one word wrapper (rules 7 and 10 in the scorecard) before dropping the name. Drop a name for being weak, never for being taken.

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

Phase 1: Generate

No availability checks in this phase, except the obvious names in Step 3.

Step 1: Get the raw material

Ask for what is missing, in one message: 1. **Every distinct job the product does, numbered.** Do not compress them to one sentence. A three-job product described in one sentence loses two jobs, and the surviving job becomes the whole naming territory by accident. 2. **What unifies those jobs.** The unifying idea is the naming territory, not any single job. 3. **The outcome the customer gets.** `Traction` works because it names what an early product wants. 4. Who it is for. 5. Words they like, and words they have ruled out. 6. Whether `.com` is a hard requirement.

Read ABOUT-ME.md and the project README first, if they exist. Ask only what they do not answer.

Step 2: Build word pools

Write the pools before any names. Names invented directly cluster around one idea.

**First, one pool per job, plus a unifying pool.** For a tool that plans meals, builds the list, and orders the food: Job 1 `plan, menu, course`; Job 2 `list, tally, basket`; Job 3 `order, deliver, stock`; **Unifying `pantry, larder, table, kitchen`**. The name usually comes from the unifying pool.

Then cut across with lexical pools: **Outcome** (streak, momentum, foothold), **Object** (ledger, anchor, compass), **Action** (tally, mark, keep), **Metaphor** (ratchet, flywheel, cairn).

Check that some word in the pools touches **every** job. If every word serves one job, rebuild the pools. This is the most common way this skill fails.

Step 3: Produce 20–30 candidates

Work in this order:

1. **Obvious names first.** Build a dozen plain compounds from the product's own nouns: who it serves plus what it hands them. Check these domains now. If one is free and literally true, you may be finished. Reaching past an available, accurate, plain name is the most expensive mistake in this skill. 2. **Then at least eight adjacent concepts.** An ordinary word one step from the product, picked for sound and a faint link: Stripe, Notion, Linear. This is the highest-yield kind and the easiest to skip. 3. **Then the other kinds:** outcome words (Traction), coined words that are spelled right on first hearing (Calendly, Typefully), and metaphors (Buffer).

Coined is not misspelled. `Flickr` and `Lyft` are respellings and score 0 on rule 2. Coin by adding a clean suffix or by fusing two real words, never by dropping vowels. A plain compound earns its place only when it names the product's actual output (`Dropbox`), not a category (`GrowthPlatform`).

Step 4: Score and present

Score each name on the ten rules. Present the top 12 as a table, highest first. **Every row has both a pro and a con.** A row with only a con is a rejection made for the founder. A row with only a pro is a sales pitch.

Cover every kind during generation. Do not cap any kind in the results. If one pattern takes eight of the top twelve after a fair fight, say so: that is a finding about the product.

**Done when** the founder has a scored list and has said which names they react to.

Phase 2: Shortlist and check availability

Step 5: Cut to 5–8

Keep the names the founder reacted to, plus any scoring 16 or more. Drop anything under 12. For each survivor, try two variants that fix its weakest rule.

Step 6: Run the checker

Pick the two or three suffixes worth having for each name, from the acceptable set. Then run the script. The path is relative to the folder that holds this SKILL.md:

python3 scripts/check-availability.py foothold.dev traction.com momentum.app
python3 scripts/check-availability.py --file candidates.txt

The script checks DNS first (a nameserver record proves a domain is taken, fast and free), then the registry's RDAP record for anything that survives. Keep lists under about 20 domains per run.

| Verdict | Means | Do | |---|---|---| | `TAKEN` | Registered | Drop it, or check whether it is parked and for sale | | `LIKELY FREE` | No nameservers and no registry record | Real candidate. Confirm at a registrar checkout | | `UNVERIFIABLE` | The script cannot tell | Search it at a registrar by hand. Never present it as available |

`UNVERIFIABLE` appears when a suffix has no RDAP server (`.io`, `.co`, `.me`, `.sh`) or when the request was rate-limited. `LIKELY FREE` is not a purchase: DNS and RDAP can lag a fresh registration, and pre