Naming Scout

Naming Scout

Two problems, kept separate:

1. Finding good names. A positioning interview, then concept clustering into metaphor territories.
2. Deciding whether a name is usable. Registry-level checks, with honest confidence labels.

Never let step 2 drive step 1. A mediocre name with a free .com is worth less than a strong name whose .com costs $2,000. Availability is a constraint to be priced, not a naming criterion.

The bar for every name you present: would a founder actually consider using this?

Workflow

1. Interview before generating

Do not generate names from a one-line request. Ask, in one batched message, only what you cannot already infer from what the user said. Full question set and the reasoning behind it: references/discovery.md.

The six things you must know before generating:

Then two decisions that change the whole back half of the run. Both are summarised here, so neither reference file is a required read.

Domain mode. Ask plainly: does it have to be .com? Would you buy from the aftermarket? Should parked domains be shown?

Clearance profile. Propose one and say in a line why those checks and not others.

Adjust on the specifics rather than the label. Open references/domain-states.md only to interpret an odd state, and references/clearance-guide.md only before running the manual checks in step 5.

If the user already answered something, do not ask it again. If the brief is rich enough already, skip straight to a one-line confirmation of your reading and generate.

Users often arrive with a name already. "Is X available?" "What do you think of X?" This is the most common way the skill gets used. It has its own path. Run the brand filter on their name first and tell them the specific weakness they had not noticed. Then run the clearance. If the exact domain is gone, check the get-, try- and the- routes before you call the name unusable. Then offer alternatives from the territory their name already belongs to. They chose that territory for a reason.

Never skip the brand-filter step. The most useful thing you can tell someone attached to a name is a concrete flaw, delivered before they learn the domain costs $8,000.

2. Extract concepts, then build territories

From the brief pull: the mechanism, the outcome, the felt emotion, the enemy or tension, the imagery, the category conventions, and what the user is deliberately not.

Group those into 4–8 naming territories. A territory is a coherent metaphor domain with an internal logic, not a word list. Adapt them to the brief; do not import a fixed taxonomy that does not fit. Territory catalogue and worked examples: references/territories.md.

State the territories to the user before or alongside the first batch. The territories are half the value: they are how the user reasons about the space after you leave.

3. Generate in rounds, not in one dump

Availability rate per territory is a signal about where to keep digging. A territory returning 5% available is mined out by everyone who used the same obvious words. A territory returning 45% is unexplored space. Report the rates; they are genuinely useful to the user and they cost nothing extra.

Availability tells you where to dig. It never tells you what is good.

4. Filter for brand quality before checking anything

Filter every candidate before it earns a lookup. Checking bad names wastes calls and pads the report.

The filter, enough for most candidates: say it aloud; spell it down a phone line; picture it in a URL bar and as a logo; ask whether it still fits when the product doubles in scope; ask whether it collides with something in the same category; ask what one sentence explains it.

Open references/brand-filter.md for the full fourteen tests only when a candidate is borderline, is a respelling, or looks like it collides with an existing brand.

Then grade its searchability ownable, contested or crowded. A name you cannot rank for costs more than an expensive domain, so it belongs in the report beside one. Short is not the same as findable: short real words are the hardest names to own in search. references/search-and-seo.md has the grading table and the correction to the exact-match domain myth, which users will raise.

A candidate with no one-sentence reason to exist is cut, however available it is.

5. Check what matters, and only that

Paths below are relative to this skill's own directory. Run them from there, or prefix with the absolute path to it.

# wide screening round: one TLD, only the states you could act on. The stderr summary
# still reports every state, so you keep the per-territory availability rate.
printf '%s\n' name1 name2 name3 | scripts/rdap.sh --tlds com --states available,for_sale

# survivors: full detail, ordered by buyability
#   available, for_sale, parked, registered, reserved, unknown
printf '%s\n' survivor1 survivor2 | scripts/rdap.sh --tlds com,io

# domain mode A (strict) and mode C (parked shown)
… | scripts/rdap.sh --tlds com --available
… | scripts/rdap.sh --tlds com --states available,for_sale,parked

# namespaces: only the ecosystems in the chosen clearance profile
scripts/clearance.sh --checks github,npm,pypi name1 name2

# defensive sweep, finalists only (same 2-5 names as the manual checks)
scripts/variants.sh finalist | scripts/rdap.sh --tlds com --available

# second use: a name you want whose exact domain is gone. --set article finds the
# get-/try-/the- route before you conclude the name is unusable.
scripts/variants.sh --set article,plural wantedname | scripts/rdap.sh --tlds com --available

Screen the wide rounds on one TLD with a state filter. Round 1 only asks what is open, so --tlds com --states available,for_sale halves the lookups and prints a handful of rows instead of eighty. The stderr summary counts every state regardless of the filter, so the per-territory rate survives it and the unverified-row warning still fires. Widen to more TLDs and the full state list once the field is down to survivors.

Pass a whole round in one invocation. The scripts parallelise, back off on 429, and cache results (registered 30 days, available 1 hour), so one call for 30 names is far cheaper and kinder to the registries than 30 calls. Add --no-cache only when a stale available would be costly. export GITHUB_TOKEN=… before a run with many GitHub checks.

When the tools cannot run (no network, no jq, a sandboxed shell) do the naming work anyway. Say plainly that nothing was verified. Territories, candidates, the brand filter and the ranking are all still worth delivering.

Never fall back to guessing availability from memory or from search results. That is the exact failure this skill exists to prevent. Mark every candidate unchecked and tell the user which commands to run.

Four checks have no reliable API: trademark, social handles, app stores and search presence. Each one is a manual search, so each one costs real time.

Run them on the finalists only, meaning the 2 to 5 names you would actually recommend. Doing them across a fifteen-name shortlist costs an hour and changes nothing: the ranking is already settled by then, and a name you are not going to recommend does not need a trademark search. Everything above the finalists gets the scripted checks and nothing more. Report the rest of the shortlist as unchecked on these four axes rather than implying they came back clean, and say so in "Check these yourself".

The one exception is a collision you can see without searching. If a candidate obviously shares a name with something in its own category, cut it in round 2, whatever its domain state says.

Report each check at the confidence its method supports. Read references/clearance-guide.md before doing any of them; it says what each check can and cannot establish.

If the market is not English-speaking, read references/naming-across-languages.md first. A name from a non-Latin script has no single spelling, so sweep the romanisations before committing to one:

scripts/variants.sh --set translit dokan | scripts/rdap.sh --tlds com

Expect single transliterated words to be gone on .com and compounds to be open. Many local country TLDs, including .bd, .pk, .lk and .np, have no RDAP and cannot be verified here.

Non-negotiable reporting rules:

• unknown is never available. Rate limits, missing RDAP servers and timeouts are unknowns. Say so.
• Absence of a website is not availability. In the source research, 12 of 12 names cleared by "no indexed website" were registered. An unindexed short brandable is more likely expensively held than free.
• Parked is registered. Label it parked, never "available".
• Never state trademark clearance. "No obvious conflict in this search" is the strongest claim available to you. It is not legal advice.

6. Report the answer first, as an HTML page in the browser

Lead with the name you would use. Not the brief, not the territories, not the method. The reader came for a decision; everything else is evidence they may or may not want.

The order, which the page enforces:

The pick, meaning one name with its reason, the domain to register and what would change your mind. Then two alternates, a line each. Then boldest and safest, a line each. Then the shortlist of 8 to 15 as collapsed rows. Then, folded shut, the brief, the territories, the rounds, and the names you cut. Last, what you could not verify.

Keep the fields short or the page stops reading as an answer: the pick's reason is one sentence, boldest and safest are one line each, and every candidate needs a why, a weakness and a verdict in a line or two. Full guidance and lengths: references/report-format.md.

Write the report to JSON, render it, and it opens in the default browser:

scripts/report.sh --schema          # the JSON shape, every field optional
scripts/report.sh report.json       # renders a self-contained page and opens it
scripts/report.sh report.json -o ~/naming-report.html --no-open

The page lands in naming-reports/ in the working directory, and the JSON is saved beside it under the same name. Both outlive the session, so the user can reread the report later and re-render it after editing a field. Your working copy of the JSON can go to a temp path. The script writes the durable copy itself. --schema is normally enough on its own; open examples/report-data.example.json only if a section's shape is still unclear.

Each domain and clearance state gets a distinct mark, so unknown can never be mistaken for available. Sections you leave out are omitted rather than shown empty, so a partial run still renders.

Then, in the terminal, say only the recommendation, the one thing that would change it, and the file path. Do not restate the report; that is what the page is for.

Rank by naming quality, positioning fit, distinctiveness, usability, clearance risk, then domain state. Reorder only when the user set a hard constraint ("must be an available .com" makes availability a filter, not a tiebreaker).

Report the names you cut, six to twelve of them, each with the direction it came from and the specific defect that killed it. The obvious word everyone suggests, the construction the reader was expecting, the near-miss that lost on one fact. "A bit generic" is not a reason. This is the only evidence the shortlist was chosen rather than generated, and it is the part a reader learns from.

A good result beats a long result. Fifteen names you would defend beat forty you would not.

7. Self-review before sending

Answer these honestly. Any "no" means another round, not a softer adjective.

• Are the top names genuinely different from each other, or three shades of one idea?
• Did any territory get explored only because it was easy?
• Would I stake my judgment on the top 3 in front of a founder?
• Is every domain state I printed one the tools actually returned?
• Did I run checks the user does not need?
• Does each "why it works" say something that could not be said about a different name?
• Is there a weakness listed for every candidate? A candidate with no stated weakness has not been examined.
• Does the cut list answer the names a reader would have asked about, or only the ones that were easy to dismiss?

Failure modes

Do not:

• open with <concept>ly, <concept>AI, <concept>Labs, <concept>HQ, or Get<concept>. These are the output of a permutation tool, and the space is exhausted.
• present forty names. Present the ones you would defend.
• ship six variants of one weak idea as if they were six ideas.
• call a parked domain available, or an unknown a negative.
• run npm and PyPI checks for a newsletter, or skip PyPI for a Python library.
• assume .com matters before asking, or assume shorter is better. Short real words are the hardest names to own in search.
• let a user pick a descriptive name for SEO reasons without telling them keyword domains stopped being a ranking signal in 2012.
• treat a transliterated word as unclaimed. Domainers hold short strings in every language.
• accept a respelling (statik for static) without checking who holds the canonical spelling, or without offering a different TLD first. Rule in references/brand-filter.md.
• describe a name as "clean, modern, memorable". Say what it does that another name does not.
• recommend a name that reads well and sounds wrong. Say it out loud first.

Reference material

Eight worked runs. Open at most one, and only when it matches the run in front of you.