Business Naming

Runs a naming project the way a professional naming agency describes its process.
Give this to your AI

Copy the skill

Paste it into a new chat in ChatGPT, Claude, Gemini or any AI you use, and send it. It starts by asking you questions. Nothing to install.

Open as plain text

This one is long (65k characters). If your AI says the message is too long, open the plain-text version, save it, and attach the file to your chat instead.
Or send your AI the link

If your AI can read websites, paste this instead:

Read https://afrodynamics.com/skills/business-naming.txt and follow it.
Use Claude Code, Codex or another agent with skills? Install it from GitHub and it runs when your request fits.
# Skill: Business Naming
# Source: https://github.com/alikibao/public-skills/tree/main/skills/branding/business-naming
# Give this whole text to your AI. It explains what to do next.
# This file bundles SKILL.md and its supporting files. When SKILL.md mentions a file such as references/example.md, find it below under "FILE: references/example.md".
# Some steps use helper scripts that need an agent able to run code: see the source link. Without them, do those steps by hand.

---
name: business-naming
description: Name a business, startup, product, app, service, feature or brand the way a top naming agency does - category and customer research, a creative framework, three independent naming teams run as subagents, a separate judging room, linguistic and trademark screening, and a proof-of-concept board that shows each finalist in real-world context. Use whenever someone wants name ideas, is stuck choosing a name, wants candidate names rated or compared, is weighing whether to rename a company or product, or needs a descriptor or tagline to sit beside a name - even if they only say "what should I call this". Not for naming variables, files or other code identifiers.
---

# Business Naming

A naming process modelled on how a leading naming agency describes its own work
(the firm behind names like Swiffer, BlackBerry, Pentium, Sonos, Azure, Impossible
and Windsurf). The principles are distilled in `references/method.md` — read it once
at the start of every project, because every role below leans on it.

The core belief: anyone can now generate 300 names in a minute, so a long list is
worth almost nothing. The value is in three things a list can't give you:

1. **A strategy sharp enough to aim at** — what the name has to say, and where we are
   *not* going.
2. **Genuinely divergent generation** — independent teams with different perspectives,
   producing far more names than feels necessary, without judging while they dream.
3. **Disciplined judging** — separating the *right* name from merely good ones, in a
   different room from the one where names were made.

## What a right name does

A right name does three jobs: it **gets attention**, it **holds attention** (it is
processing-fluent — easy to say, with something inside the brain can grab), and it
**surprises** (original in its category and unexpected *from this company*). The
target is *surprisingly familiar*. Comfortable names feel safe, test well, and then
vanish — that is the comfort trap, and most of this process exists to escape it.

## Pick the entry point

| Situation | Start at |
|---|---|
| New company, product, app or feature needs a name (default) | Phase 0, run everything |
| User has an existing name and wonders whether to change it | `references/renaming.md`, then the full project only if the case holds |
| User already has candidates and wants them judged | A light Phase 0 (what it is, markets, the four questions), then Phase 4 with their names → screening → board. Offer a small Team A cycle if they want alternatives |
| Name is chosen; they need a descriptor, tagline or naming system | Phase 6 only |

**Depth.** Run *Standard* (two generation cycles) by default. Run *Sprint* (one cycle,
smaller quotas) when the user wants speed or says "quick". Say which depth you're
running in one line at the start.

| | Sprint | Standard |
|---|---|---|
| Generation cycles | 1 | 2 |
| Names per team per cycle | 80+ | 150+ (cycle 1), 100+ (cycle 2) |
| Shortlist sent to screening | ~15 | 25–30 |
| Finalists presented | 8–10 | 10–15 |

## The agency: rooms and roles

You are the **project lead**. You talk to the user (the client), write the briefs,
run the rooms in order, and keep generating and judging apart. Each specialist has a
brief in `agents/`.

| Room | Role | Brief | Runs |
|---|---|---|---|
| Discovery | Landscape Scout | `agents/landscape-scout.md` | parallel with Insight Analyst |
| Discovery | Insight Analyst | `agents/insight-analyst.md` | parallel with Landscape Scout |
| Strategy | You + the user | this file, Phase 2 | — |
| Strategy | Cartographer | `agents/cartographer.md` | after the framework |
| Dreaming room | Naming Teams A, B, C | `agents/naming-team.md` + one assignment each | parallel, isolated |
| Judging room | Judge | `agents/judge.md` | twice: shortlist, then finals |
| Screening | Linguist | `agents/linguist.md` | parallel with Screener |
| Screening | Trademark & Availability Screener | `agents/trademark-screener.md` | parallel with Linguist |
| Presentation room | Proof-of-Concept Studio | `agents/poc-studio.md` | last |

Below, `<skill-dir>` is the folder this SKILL.md lives in and `<ws>` is the project
folder. Pass both, as absolute paths, to every role.

**Running the roles.** When an Agent/Task tool is available, run each role as its own
subagent, and launch roles marked *parallel* in the same turn. Subagents can't see this
conversation, so everything they need must be in files in the project folder. A prompt
like this works:

> Read `<skill-dir>/agents/judge.md` and follow it. Mode: shortlist. Skill directory:
> `<skill-dir>`. Project folder: `<ws>`. Inputs: `<ws>/02-framework.md`,
> `<ws>/05-judging/merged.json`. Write your output to `<ws>/05-judging/`.

If you can continue an agent later (e.g. a SendMessage tool), reuse
the Judge for the finals so it keeps its reasoning.

**No subagents?** Play each role yourself in sequence, reading its brief first. For
Team C, write the analog assignment and generate from it *before* re-reading the
product files, so its perspective stays genuinely different. Keep the dreaming and
judging passes as separate steps — never cut names while generating.

**Project folder.** Create `naming-<slug>/` in the working directory:

```
naming-<slug>/
  00-intake.md
  01-research/        landscape.md, insight.md
  02-framework.md
  03-map.md, 03-sparks.txt
  04-dream/c1/        assignment-a.md, team-a.jsonl, team-a-notes.md, ... (c2/ for cycle 2)
  05-judging/         merged.json, longlist.md, shortlist.json
  06-screening/       linguist.md/.json, trademark.md/.json
  07-final/           finalists.json, final.json, board.html, report.md
```

Set up a task list with one item per phase so the user can see progress.

## Phase 0 — Intake

Gather everything in one round (AskUserQuestion if available, otherwise a short
numbered message). If the user already said most of it, confirm your reading and fill
gaps instead of re-asking.

- What it is, what it does, who it's for, what stage it's at.
- Markets and languages the name must work in (drives linguistic and trademark checks).
- The **four questions**: *How do you define winning? What do you already have that
  helps you win? What do you need in order to win? What does the name need to say —
  or help you say?*
- Constraints: domain needs, length, words to avoid, the parent brand and its existing
  names ("unexpected" is relative to the company — Azure surprised coming from
  Microsoft; from a company known for playful names it wouldn't have).
- The current name and its history, if this is a rename.

Don't stall on the four questions. If the user can't answer them, draft answers from
what you know (and from research, once it's in) and let them react. Founders often
discover they define "winning" differently from each other — surfacing that is worth
the question by itself. Write `00-intake.md`.

## Phase 1 — Discovery (parallel)

Spawn the **Landscape Scout** and **Insight Analyst** together.

- `landscape.md`: names in the category classified by type, the patterns that make up
  the category's "sea of sameness", a *not-going-there* bucket, white space, and what
  would be unexpected from this particular company.
- `insight.md`: a raw list of everything the product has, what customers need and say
  in their own words, the emotional truths of the category (nobody *wants* to mop),
  and benefit ladders climbing to 3–5 candidate **ultimate benefits** (fiber → regular
  → healthy gut → *I feel lighter*).

## Phase 2 — Strategy: the creative framework

Write `02-framework.md` yourself from intake and research. Think of it as a window the
teams walk through, not a checklist they must conform to — so keep it short (one page):

- Positioning in one line, and the **ultimate benefit** chosen (plus a runner-up).
- What the name must do (2–4 jobs) and the *not-going-there* bucket.
- **Desired feel** in a few plain words (e.g. "fast, reliable" or "light, warm") — the
  Linguist scores sound symbolism against it.
- The **surprise test**: what would be unexpected in this category *from this company*.
- Name-type range (real word in a new context → compound → coined). Descriptive names
  only if something exceptional demands clarity; the descriptor can carry the category.
- Hard constraints.

Then spawn the **Cartographer**. First draw random far domains for synchronicity —
`python <skill-dir>/scripts/name_tools.py sparks --n 6 > <ws>/03-sparks.txt`. A script
gives real randomness; picks you make yourself drift
toward the familiar. If a name vault exists (see below), give it to the Cartographer as
one more territory. The map (`03-map.md`) covers the whole ocean before anyone dives:
30–50 territories with raw word-stock, analog categories for Team C, twist options for
Team B, and a suggested split.

**Checkpoint.** Show the user, compactly (≤ 20 lines): the ultimate benefit, the
not-going-there bucket, the desired feel, and the three team setups you plan. Ask
whether anything is off before the teams start — this is the cheapest moment to
redirect. If the user said to just run it, state your choices and carry on.

## Phase 3 — The dreaming room: three teams

Write one assignment file per team in `04-dream/c1/`. The agency found good names
come from individuals and pairs, not brainstorm groups (peer pressure, evaluation
cascades) — and that three teams looking from three different angles produce three
genuinely different lists. That difference is the whole point, so protect it:

- **Team A — Insiders.** Knows everything: intake, research, framework, its share of
  the map. Names straight at the strategy.
- **Team B — The Twist.** Same product, plus one deliberate perspective shift: an added
  ingredient or feature, an amplified benefit, a different user or moment of use (the
  agency's example: the fiber product *also gives energy*). Pick the twist that pulls
  toward a plausible future of the brand. Gets different territories from Team A.
- **Team C — Outsiders.** Never told the real product. Gets only an analog brief: a
  different category that shares the ultimate benefit or emotional truth (fiber →
  *feeling lighter* → athletic performance gear). Their names get transplanted later,
  which is where many surprises come from. Its assignment must not mention the real
  product, company or category.

Each assignment contains: the brief for that team, its territories with word-stock
pointers, two random sparks each (draw fresh with the `sparks` command), the quota,
output paths, and the skill directory. Spawn A, B and C in parallel. Each writes
`team-x.jsonl` and `team-x-notes.md`.

Why the quotas are high: quantity leads to quality. Amateur lists stop at 50–100 names,
which is exactly where everyone else stopped too. The agency works through roughly
2,000 per project; the trash is necessary.

## Between cycles — sonar and redial (Standard only)

Merge and read the sonar:

```
python <skill-dir>/scripts/name_tools.py merge "<ws>/04-dream/c1/*.jsonl" --out <ws>/05-judging/c1-merged.json
```

It reports names per team and territory, favourite rates (a rich vein), dry
territories, and **cross-team collisions** — names two independent teams both reached.
Treat collisions as a warning that the name is probably the obvious move, not as a
vote in its favour. Read the team notes, then decide per team: **keep** (assignment
working), **redial** (change the assignment — new twist, new analog), or **dive** (go
deeper on a vein that showed gold). Like mapping a seabed before diving, cycle 2 goes
where the sonar showed something, plus one long-shot territory nobody tried.

Optional user check-in: share 10–15 *directions* — territories with two or three
example names each — framed as speculation, not a shortlist. Ask only whether there's
a vein to dive deeper into or avoid. Don't ask them to pick favourites yet: early
voting pulls everyone into the comfortable zone.

Write cycle-2 assignments in `04-dream/c2/` (new sparks, notes from cycle 1 included)
and spawn the teams again.

## Phase 4 — The judging room: shortlist

Merge everything:

```
python <skill-dir>/scripts/name_tools.py merge "<ws>/04-dream/**/*.jsonl" --out <ws>/05-judging/merged.json
```

Spawn the **Judge** in *shortlist* mode. The Judge never generated these names, which
is the point. It culls to names with energy, maps them into zones (invisible / tension /
noise), scores them on `references/evaluation.md` with gut scores of 1–10 and **no
sevens** (a seven is a way to avoid deciding), and writes a shortlist with a spread of
name types, all teams that earned a place, and at least two names expected to
polarize the client. The longlist is kept so names can come back later.

## Phase 5 — Screening (parallel), then finals

Spawn the **Linguist** and the **Trademark & Availability Screener** together on
`shortlist.json`. Both follow one rule taken from the agency: when a name hits a
problem, don't just kill it — ask *"how could we modify it so it works?"* (a respelling,
a compound, a descriptor, a neighbouring root) and propose the fix.

Then run the **Judge** in *finals* mode with the screening results. It picks the
finalists, applies screening (modified, kept with a noted risk, or moved off the table),
and lists a few strong *off the table — for now* names. Read `finalists.json` yourself
before going on: the list should be one you'd defend in front of the client, include
real range, and contain names that make you a little nervous.

## Phase 6 — The presentation room: proof of concept

Never present a bare list. People rarely practise making creative decisions; in a
spreadsheet, the safest name wins. In context, names come alive.

Spawn the **Proof-of-Concept Studio**. For each finalist it writes a descriptor that
carries the category (Feather — *the lightweight fiber you need*; the agency's Swiffer
leaned on a "quicker picker-upper" style line), a believable news headline, a premium ad
line, a short story of why this name, and a line of it used in real life — then runs the
one internal test that matters: *in the first split second, do you lean toward
believing it?* It builds `final.json` and runs:

```
python <skill-dir>/scripts/build_board.py <ws>/07-final/final.json --out <ws>/07-final/board.html
```

Look at the board (screenshot it if you can) before showing anyone.

## Phase 7 — The client room

Deliver two things:

1. **The board** — publish it as an artifact if the environment supports artifacts
   (follow that tool's own instructions); otherwise send the HTML file.
2. **A naming report** — a document in whatever format the environment prefers for
   documents (a docs artifact or connector if one exists, otherwise markdown). Contents:
   the framework in brief; the process in numbers (names per team and cycle, territories
   explored, how many screened); finalists with rationale, zone, scores and risks;
   off-the-table names; next steps — attorney clearance in each market, native-speaker
   checks, domain and handle acquisition, a quick test of recall and spelling-from-hearing
   with real people.

In chat, keep it short: the two or three you'd recommend and why, and that the
tension-zone names are in the set on purpose.

**Handling reactions** — this is where great names die, so it gets care:

- Start with curiosity: "That's interesting — what's the reaction underneath?" Separate
  *I don't like it* from *it doesn't do the job*.
- A polarizing name has energy. A name nobody objects to is usually invisible. Use the
  user's own reactions to explain the comfort trap.
- Move rejected strong names *off the table for now*, not into the bin, and bring them
  back once the user has lived with the shortlist for a while. Every name the agency
  is famous for was rejected at first (BlackBerry was dismissed in the first meeting and
  won on the second pass — partly because big competitors would never have dared).
- Turn objections into problems: "I wish it felt less clinical" becomes the brief for a
  targeted mini-cycle (one team, ~60 names in that vein, then Judge and screening on the
  new candidates only).
- Don't oversell. The user decides. Your job is that they decide with the strongest
  options in front of them, seen in context.

Optional follow-ons once a name is chosen: nomenclature (descriptor, positioning line,
how sub-products get named), a rename launch story (`references/renaming.md`), and a
simple 90–120-day tracking plan (unaided recall, spelling-from-hearing, search share).

## The name vault

Strong names that don't fit this project are assets. The agency files names under
abstract qualities rather than categories — names made for a small car sit beside names
made for a small processor — so they cross-pollinate later. At the end of a project,
save 20–40 of the best unused names tagged by quality (*small, fast, light, reliable,
warm, bold…*), one line each. Keep the vault where it will persist: a project document
called `name-vault.md` if a Projects tool is available, otherwise ask the user where
they'd like it. At the start of the next project, hand the vault to the Cartographer.

## Honesty and limits

- Trademark, domain and handle checks here are **preliminary knockout screens, not legal
  clearance**. Say so in the report and on the board, and recommend an IP attorney in
  each market before money is spent.
- A model's slang and connotation checks can miss things; recommend native-speaker
  checks for every serious market.
- Sound symbolism describes tendencies, not laws. Use it to tune and break ties, never
  to veto a name with meaning and energy.

## How to talk about names (all phases)

Use the agency's coaching language with the user and in every brief, because it keeps
people generating instead of defending: "That's interesting." "I wouldn't have thought
of that." Turn a kill into a problem — "I wish we could make that easier to spell",
"How could we modify that word so it's legally available?" During generation, nobody
evaluates; they speculate. Judging happens later, in its own room.

## Reference files

- `references/method.md` — the principles behind every phase (read first)
- `references/evaluation.md` — the rubric, zones, red flags and gut-score rules
- `references/sound-symbolism.md` — processing fluency and what sounds tend to signal
- `references/territories.md` — where names come from: territory families, name types, moves
- `references/renaming.md` — whether to rename, and how to launch one
- `scripts/name_tools.py` — `check`, `merge`, `phonetics`, `sparks`, `handles`
- `scripts/build_board.py` — the proof-of-concept board


======== FILE: agents/cartographer.md ========

# Cartographer

Map the whole ocean before anyone dives. The story the agency tells: treasure hunters
kept finding *a* shipwreck off the coast and spending everything on it; the one who
found the gold ship first mapped the entire seabed, decided where the odds were, and
only then dived. Your map stops the naming teams from diving on the first obvious
territory.

**Inputs:** `00-intake.md`, `01-research/landscape.md`, `01-research/insight.md`,
`02-framework.md`, `03-sparks.txt`, and the name vault if the lead gives you one.
**Output:** `03-map.md`.

Don't write finished names. Collect *word-stock* — words, roots, terms, facts, idioms —
that the teams will turn into names.

## Steps

1. **Chart 30–50 territories** a name could come from, spanning near to far (see
   `<skill-dir>/references/territories.md` for families):
   - **Near** — the ultimate benefit and its metaphors (lightness: air, feathers, lift,
     floating, weightlessness).
   - **Mechanism** — the real science or craft behind the benefit (how lift actually
     works; what happens in the gut).
   - **Classical stock** — Greek and Latin roots for the core ideas; mythological
     figures, objects and places with the right associations; elements of the periodic
     table and their lore.
   - **Language of the feeling** — idioms, expressions, compliments, everyday phrases
     people use for the state you're after; the sound or verb of the action.
   - **Far** — every domain in `03-sparks.txt`, plus a few unexpected picks of your own.
     This is where synchronicity happens: connections between seemingly irrelevant
     things are where the agency says creativity lives (Impossible had nothing to do
     with burgers).
   - **Local** — words, places and landscapes from the target markets' languages.
   - **Vault** — abstract-quality names from earlier projects, if provided.

2. **For each territory** give: one line on why it might pay off; 8–15 items of raw
   word-stock; and a dive rating — *rich*, *promising* or *long shot*. Keep the long
   shots on the map on purpose.

   Look things up rather than relying only on memory — root dictionaries, mythology
   references, technical glossaries, idiom lists. The agency's edge is enriched
   databases: a periodic table loaded with articles and lore yields far more than the
   bare table. Ask questions *about* a territory (how do gliders find rising air? what
   do falconers call a bird's first flight?) instead of asking for names.

3. **Analog categories for Team C** — three categories outside this one that share the
   ultimate benefit or emotional truth. For each, write a one-paragraph analog brief
   that never mentions the real product, company or category (fiber that makes you
   feel lighter → "performance running gear that makes athletes feel weightless").

4. **Twist options for Team B** — three perspective shifts (an added ingredient or
   feature, an amplified benefit, a different user, a different moment of use), each
   with a line on where it would pull the names.

5. **Suggested split** — which territories go to Team A and which to Team B (minimal
   overlap), and which analog brief you'd give Team C.

## Output format

```
# Treasure map — <project>
## Territories
### <territory>  — rating
why: ...
word-stock: ...
## Analog briefs for Team C
## Twist options for Team B
## Suggested split
## Sources
```


======== FILE: agents/insight-analyst.md ========

# Insight Analyst

You climb from what the product *is* to what people ultimately *get* from it. The name
very often lives at the top of that ladder, not at the bottom: a fiber supplement's
names usually say "fiber", but what users ultimately want is to *feel lighter*. And the
category's unspoken emotional truths are gold — nobody actually wants to mop, which is
why a mop renamed into something playful (Swiffer) beat one named for being a mop.

**Inputs:** `00-intake.md` in the project folder.
**Output:** `01-research/insight.md`.

Don't suggest names.

## Steps

1. **Product inventory** — a raw list of everything the product has: attributes,
   features, ingredients, mechanisms, how it's made, origin story, founder quirks,
   anything odd or specific. More is better; specifics make better raw material than
   generalities.

2. **The people** — who uses it, the job they hire it for, what they expect, what
   frustrates them, and the words they actually use. Search reviews, forums, Reddit,
   app-store reviews, Q&A threads and social posts for the category. Capture short
   fragments of real customer language (a few words each) — they are raw material for
   names and descriptors.

3. **Emotional truths** — what people feel about this category that brands rarely say
   out loud (it feels like medicine; it's a chore; it's embarrassing; it's intimidating).

4. **Benefit ladders** — for the 3–5 strongest attributes, climb in one line each:
   *attribute → functional benefit → emotional benefit → ultimate benefit*.

5. **Candidate ultimate benefits** — 3–5 of them, each with one line on why it matters
   to people and how ownable it is in this category. Mark the one you'd recommend.

6. **Magic bullet check** — say plainly whether the product has a genuinely unique
   feature. Most don't, and that's normal: then the name has to carry the ultimate
   benefit or an attitude rather than a feature claim.

## Output format

```
# Insight — <project>
## Product inventory
## The people (needs, frustrations, their words)
## Emotional truths
## Benefit ladders
## Candidate ultimate benefits   (recommended one marked)
## Magic bullet check
## Sources
```


======== FILE: agents/judge.md ========

# Judge — the judging room

You did not generate these names. That is the point: generating and judging happen in
different rooms, because judging while dreaming kills the dream. Now that the dreaming is
done, your job is the part that AI can't make cheap — separating the *right* names from
the good ones and the okay ones.

Read `<skill-dir>/references/evaluation.md` and `<skill-dir>/references/sound-symbolism.md` before you start.

You run in one of two modes; the lead tells you which.

## Mode 1 — Shortlist

**Inputs:** `02-framework.md`, `01-research/landscape.md`, `05-judging/merged.json`,
team notes in `04-dream/`.
**Outputs:** `05-judging/longlist.md`, `05-judging/shortlist.json`.

1. **Cull.** Read every name. Keep any that has *energy* — makes you look twice — or does
   the framework's job unusually well. Don't keep "fine". Target 60–80 (Sprint: 40).
   For Team C's names ask: *transplanted into this category, what would this do?* Some
   of the best surprises arrive this way. Treat cross-team collisions with suspicion:
   if two blind teams both found it, it's probably the obvious move.

2. **Map the zones** (the comfort trap):
   - **Invisible** — familiar, low distinctiveness, everyone agrees, nobody remembers.
   - **Tension** — familiar enough to process, surprising enough to split the room. Target.
   - **Noise** — distinctive but nothing to grasp; hard to say, spell or place.
   Most of the shortlist should be tension. Keep an invisible-leaning option only if the
   framework genuinely demands instant clarity.

3. **Score** the cull with the rubric (each criterion 1–10) and give a **gut score
   1–10 with no sevens** — sevens are how judges avoid deciding.

4. **Shortlist** 25–30 (Sprint: ~15) for screening, with deliberate spread: at least
   three name types; every team that earned a place; at least two names you expect to
   polarize the client. Include a few you're unsure about — screening may rescue or
   sink them.

`shortlist.json`:
```
{"names": [
  {"name": "Feather", "team": "A", "territory": "lightness", "type": "real word, new context",
   "zone": "tension", "gut": 9,
   "scores": {"original": 9, "fluency": 9, "surprise": 8, "believability": 8, "strategy": 9, "legs": 8},
   "says": "Fiber that makes you feel light, not medicated.",
   "worry": "Real word — trademark crowding outside the category."}
]}
```

`longlist.md`: the full cull as a compact table (name | team | zone | gut | one-line
note), so names can be brought back later.

## Mode 2 — Finals

**Inputs:** everything above plus `06-screening/linguist.*` and `06-screening/trademark.*`.
**Output:** `07-final/finalists.json`.

1. Apply the screening honestly. A name with a *conflict* is replaced by a screener's
   proposed modification if that keeps its energy, otherwise moved off the table with
   the reason. *Caution* names can stay, with the risk stated.
2. Pick 10–15 finalists (Sprint: 8–10). Mark 2–3 as `recommended`. Keep real range —
   the client should see different strategies, not ten versions of one idea — and keep
   at least one name that makes you slightly nervous.
3. List 4–8 **off the table — for now**: strong names that missed this round, each with
   a line on why they still have value.

`finalists.json`:
```
{"names": [
  {"name": "...", "type": "...", "territory": "...", "zone": "tension", "gut": 9,
   "recommended": true, "says": "one line", "why": "2–3 sentences",
   "risks": ["from screening, plainly stated"]}
 ],
 "off_table": [{"name": "...", "note": "why it still has value"}]}
```

## How to write

Write kills as problems, not verdicts: "this would work if it were easier to spell" is
more useful than "too hard to spell", and sometimes the fix is obvious once written
down. Be decisive in scores and generous in curiosity.


======== FILE: agents/landscape-scout.md ========

# Landscape Scout

You map the category so the naming teams know where *not* to go. The first hypothesis
on almost every project is that the category's existing names cluster into a few
comfortable patterns — Fiber One, Benefiber and their cousins all announce the
ingredient — and that the winning name will come from somewhere else. Your job is to
prove or disprove that with evidence, and to describe the patterns precisely enough
that the teams can steer around them.

**Inputs:** `00-intake.md` in the project folder.
**Output:** `01-research/landscape.md` (aim for 1–2 pages; the teams must be able to use it fast).

Don't suggest names. That happens in another room.

## Steps

1. **Collect the names in play** — 15–40 of them: direct competitors, adjacent players,
   recent launches and well-funded newcomers, in each target market. Search the web
   (category + "brands", comparison and review sites, retailer shelves, app stores,
   startup directories, local directories for each market). Include the parent brand's
   own portfolio if there is one.

2. **Classify each name** by type — descriptive, suggestive, real word in a new context,
   compound, blend, coined, initials/acronym, founder name — and note the roots and
   building blocks everyone reuses (e.g. *fiber-*, *-ify*, *-ly*, *pay*, *nova*, *flow*,
   dropped vowels).

3. **Describe the sea of sameness**: the 3–6 conventions most names fall into, each with
   two or three examples. Be specific ("names that state the ingredient", "Latin-ish
   wellness coinages ending in -a") rather than vague ("generic names").

4. **Write the not-going-there bucket**: bullets the teams can check against. We may
   come back to one of these later, but we start knowing they're taken.

5. **Find the white space**: name types, sound shapes, emotional territories or
   attitudes nobody in the category owns.

6. **The company lens**: what kinds of names does this company — or its founders, or its
   parent brand — usually have? What would be genuinely unexpected *from them*?

7. **Strong names worth learning from**: any name in or near the category that clearly
   works, with one line on why.

## Output format

```
# Landscape — <project>
## Names in play            (table: name | owner | market | type | note)
## Sea of sameness          (3–6 patterns with examples)
## Not going there          (bullets)
## White space
## Company lens
## Names worth learning from
## Sources                  (links)
```


======== FILE: agents/linguist.md ========

# Linguist

You test two things for every shortlisted name: whether the brain can process it easily
(processing fluency), and whether its sounds and meanings work — in every market it has
to live in. The agency ships every serious shortlist to linguists around the world and
runs each name through its own fluency and sound-symbolism software; you are both.

Read `<skill-dir>/references/sound-symbolism.md` first.

**Inputs:** `00-intake.md` (markets and languages), `02-framework.md` (desired feel),
`05-judging/shortlist.json`.
**Outputs:** `06-screening/linguist.md` (readable) and `06-screening/linguist.json`.

## Steps

1. **Run the structural readout** as a starting point:
   ```
   python <skill-dir>/scripts/name_tools.py phonetics --from <ws>/05-judging/shortlist.json --profile <desired feel words>
   ```
   It works from spelling, not sound, so treat it as a prompt for your own judgement.

2. **For each name:**
   - **Say it.** Syllables, stress, and every plausible pronunciation (if there are two,
     that's a finding).
   - **Hear it, spell it.** If someone heard it once on a podcast, could they type it into
     a browser correctly? (Codium failed this; Windsurf passes.)
   - **Fluency.** Real word or familiar parts? Consonant–vowel rhythm? Awkward clusters?
     Is there something inside it the brain can grab?
   - **Feel.** Do its sounds match the desired feel in the framework? If not, can a small
     change fix that?
   - **Each target language.** Meaning, near-homophones, slang, rude or unlucky
     associations, and whether native speakers can pronounce it. Search the web when you
     are unsure about slang or connotations, and say how confident you are.

3. **Verdict:** `clear`, `caution` or `problem`, with a one-line reason — and for
   caution/problem, a modification that would fix it if one exists.

4. List the markets where a **native-speaker check** is still needed (any market where
   your confidence is less than high).

`linguist.json`:
```
{"names": [
  {"name": "...", "pronunciations": ["..."], "spell_from_hearing": "easy|mixed|hard",
   "feel_fit": "good|partial|poor", "market_notes": {"<language>": "..."},
   "verdict": "clear|caution|problem", "reason": "...", "fix": "..."}
 ],
 "native_checks_needed": ["<language>", "..."]}
```


======== FILE: agents/naming-team.md ========

# Naming Team

You are a two-person naming team working in the dreaming room. Read your assignment
file — and only your assignment file plus the files it names. (If you are Team C you
are working blind to the real product on purpose. Don't go looking for it; the blindness
is what makes your list different.)

**Why pairs.** When the agency tracked where its good names actually came from, the
answer was individuals and two-person teams — not brainstorm groups, where peer
pressure and a cascade of evaluation slow everything down, and not outsiders without
the context. A pair gets two perspectives without a committee.

**The approximate-thinking line.**

```
bizarre · absurd · "illegal"  ←——  approximate thinking  ——→  safe · workable
```

Start at the bizarre end and work toward *approximate*. Stop there. Making things safe
and workable is the judges' job, and they will do it anyway; your job is to hand them
things nobody else would have found. Every list contains trash. The trash is necessary —
it's how you get to the good ones.

## Work in three passes

### Pass 1 — Dig (Partner 1, the explorer)
For each assigned territory, look things up and collect raw word-stock: roots,
technical terms, idioms, facts, odd details, names of things inside the territory. Ask
questions about the territory rather than asking for names. Spend part of the dig on
your two sparks: *what could this unfamiliar field teach us about this brief?* Expect
roughly a third of spark-digs to give you a new angle; that's a good hit rate.

### Pass 2 — Craft (Partner 1)
Turn the word-stock into names, using every move:
- **Real word, new context** — an everyday word that's surprising in this category
  (Feather for fiber, BlackBerry for a device, Azure for a cloud).
- **Compound / collision** — two words that spark (DreamWorks, Windsurf, HubSpot).
- **Blend** — two words fused into one.
- **Truncate, extend, re-suffix** — clip a word or give it a new ending.
- **Root-craft & coinage** — build from Greek or Latin roots, or coin a word that
  sounds like it means something (Pentium leaned on *pent-* and the feel of an element).
- **Sound-play** — consonant-vowel rhythm, repetition, plosives for punch (Sonos).
- **The sound or verb of the action** — what doing the thing sounds like (Swiffer).
- **A claim or attitude** — a word that makes a promise (Impossible).
- **Letter energy** — X, Z, K used on purpose, not by reflex.
- **Respellings** — sparingly; each one costs spelling-from-hearing.

### Pass 3 — Build (Partner 2, the speculator)
Read Partner 1's list cold. Don't evaluate — speculate. Pick the 20+ names with the most
energy and riff 3–5 variations on each. For broken-but-interesting ones, say "I wish we
could make this ___" and then do it. Finish with a burst in whichever territories Partner
1 underused.

Hit the quota. The names past the point where it feels finished are often where the
surprises are.

Never drop a name because it might be taken, might be hard to sell, or feels too weird.
Those decisions belong to another room.

## Output

1. **`team-<x>.jsonl`** — one JSON object per line:

   ```
   {"name": "Feather", "territory": "lightness", "move": "real word", "spark": "fiber that makes you feel light", "team": "A", "favorite": true}
   ```

   - `spark` is ≤ 12 words on what the name is reaching for.
   - Mark 10–15 `favorite: true` — the names with the most *energy*, not the safest.
   - Write the file with a file tool or a short script, then validate it:
     `python <skill-dir>/scripts/name_tools.py check <path>` and fix any errors.

2. **`team-<x>-notes.md`** — at most 25 lines: the richest territories, the dry ones,
   what the sparks yielded, where you'd dive next cycle, and your favourites with one
   line each on what's charged about them.

Return a two-line summary to the lead: how many names, and the territory that surprised
you most.


======== FILE: agents/poc-studio.md ========

# Proof-of-Concept Studio — the presentation room

In a spreadsheet, the safest name wins. In context, names come alive. Most clients have
little practice making creative decisions, so the agency never hands over a bare list: it
puts every name into the world first — a premium print ad, a news headline, a product on
a shelf — and checks internally that each one passes a single test before any client
sees it: **in the first split second, do you lean toward believing it?**

**Inputs:** `00-intake.md`, `02-framework.md`, `07-final/finalists.json`, and the
screening files for domains and risks.
**Outputs:** `07-final/final.json` and `07-final/board.html`.

## Steps

1. **Write the context copy for each finalist:**
   - `descriptor` — ≤ 8 words that tell people what it is, so the name doesn't have to
     ("Feather — the lightweight fiber you need"). Consumers aren't stupid; a good
     descriptor lets the name stay surprising.
   - `headline` — a believable news headline about the launch.
   - `ad_line` — one line for a premium black-and-white print ad (e.g. "Mornings that run
     well run on Feather.").
   - `story` — 2–3 sentences: what the name says and why it's unexpected here.
   - `in_use` — the name in a real sentence someone would say or text.
   - `domain` — the best realistic domain from screening.

2. **Run the believability test.** Read each name in its contexts. Mark `believable`
   as `yes`, `stretch` or `no`. For a stretch, try a better descriptor first — often the
   descriptor carries the category so the name can stay bold. If a name is still a `no`,
   tell the lead rather than quietly dropping it.

3. **Write `final.json`** in the schema documented at the top of
   `<skill-dir>/scripts/build_board.py`. Carry over `type`, `territory`, `zone`, `gut`,
   `recommended`, `says` and `risks` from the finalists, and `off_table` too. Put the
   recommended names first.

4. **Build and check the board:**
   ```
   python <skill-dir>/scripts/build_board.py <ws>/07-final/final.json --out <ws>/07-final/board.html
   ```
   If you can, screenshot it and look: every name should read cleanly in every tile.

Return to the lead: which names are `stretch` or `no` and why, in a few lines.


======== FILE: agents/trademark-screener.md ========

# Trademark & Availability Screener

You are the paralegal knockout screen, not the attorney. Your job is to catch obvious
conflicts early — before anyone falls in love — and to *save* good names by modification
wherever possible. When a name looks blocked, ask the agency's question: *how could we
modify that word so it's legally available?*

**Inputs:** `00-intake.md` (markets, category, constraints), `05-judging/shortlist.json`.
**Outputs:** `06-screening/trademark.md` (readable) and `06-screening/trademark.json`.

Put this line at the top of the markdown: *Preliminary knockout screen — not legal
advice or clearance. Confirm with an IP attorney in each market before committing.*

## Steps (for each name; aim for 3–6 lookups per name and work in parallel where you can)

1. **Category conflicts.** Search the web for the exact name and close variants together
   with the category, in each target market. Same or neighbouring goods/services is a
   red flag; a famous mark in *any* category is a red flag.

2. **Registries.** Identify the likely Nice class(es) for the product, then check the
   trademark databases for the target markets where you can reach them — for example the
   USPTO trademark search (US), EUIPO eSearch or TMview (EU), UK IPO, WIPO Global Brand
   Database (international), CIPC (South Africa), IP Australia, CIPO (Canada). If a
   registry can't be fetched, say so and write out the exact search the user should run.

3. **Digital.** Run `python <skill-dir>/scripts/name_tools.py handles <names...>` for
   variant lists. Check whether the main domain is live and what's on it, the realistic
   alternatives, handles on the platforms that matter for this business, and
   **search ownability**: does searching the name drown in unrelated results? Could a
   customer find the company? (A name nobody can search is a quiet tax every day.)

4. **Risk rating:** `clear`, `caution` or `conflict`, with evidence links.

5. **Save it.** For caution/conflict names, propose 1–3 modifications that keep the
   energy — a compound, a descriptor, a minimal spelling change, a neighbouring root, a
   different domain strategy — and mark them as needing their own check.

`trademark.json`:
```
{"names": [
  {"name": "...", "classes": ["5"], "risk": "clear|caution|conflict",
   "evidence": ["<url> — what it shows"], "domain": "status and best option",
   "handles": "summary", "search_ownability": "good|crowded|poor",
   "modifications": ["..."], "notes": "..."}
]}
```


======== FILE: references/evaluation.md ========

# Evaluation rubric

Used by the Judge (shortlist and finals) and by the lead when a user brings their own
candidates. Judge in context where possible — a name read in a headline is a different
name from the same word in a spreadsheet.

## Criteria (score each 1–10; never 7)

| Criterion | The question to ask |
|---|---|
| **Original** | Is it new *in this category*? Does it avoid the landscape's not-going-there bucket? (Original ≠ coined: Feather is original in fiber.) |
| **Fluency** | Can you say it at first sight, spell it after hearing it once, and remember it tomorrow? Is there something inside it to grasp? |
| **Surprise** | Is it unexpected in this category *and from this company*? Does it make you look twice? |
| **Believability** | In context, in the first split second, do you lean toward believing it belongs to this business? |
| **Strategy** | Does it do the framework's jobs — say, or open the door to saying, what we need to say? |
| **Legs** | Can it carry a descriptor, a story, a product family, a new market? Could it become a verb? Will it age well? |

**Gut score:** one number 1–10, from the first honest reaction, **no sevens**. A seven
is a way of not deciding; force yourself to 6 or 8.

Don't average the criteria into the gut score. A name with one 4 and a 10 in surprise
can be the right name; a name with six 7-ish scores is usually invisible.

## Zones (the comfort trap)

Plot familiarity (how easily the brain processes it) against distinctiveness (how much
it stands out in the category):

| | Low distinctiveness | High distinctiveness |
|---|---|---|
| **High familiarity** | **Invisible** — safe, consensus, forgettable (Ready Mop, Fiber One) | **Tension** — surprisingly familiar; splits the room; the target (Swiffer, BlackBerry, Feather) |
| **Low familiarity** | Dead — skip | **Noise** — distinctive but nothing to grasp; hard to say, spell or place |

Most of a shortlist should sit in tension. Coined names can live in tension when they
feel familiar (Pentium, Sonos, Febreze sound like they already mean something).

## Red flags

- Descriptive in a category full of descriptive names.
- Fails hear-it-spell-it (the Codium problem).
- Search-hostile: a common word with no category twist and thousands of unrelated
  users, so customers can't find you. (Real words in new contexts are fine when the
  category makes them ownable.)
- Negative, rude or unlucky meaning in a target market.
- Collides with a famous mark, or with anyone in the same or neighbouring goods/services.
- Trend morphemes that date fast (-ify, -ly, dropped vowels, gratuitous .ai styling).
- Only works with an explanation.

## Not red flags

- "I don't like it" on first read — record it, then look for what's underneath.
- A split reaction — that's energy.
- Not describing the product — the descriptor can do that job.
- Unfamiliar at first sight but fluent once heard.

## Spread checklist for any shortlist or final set

- At least three name types (real word in new context, compound, coined, claim…).
- Ideas from more than one territory and more than one team.
- At least two tension names that will polarize the client.
- One option a cautious stakeholder could live with — clearly labelled as such.


======== FILE: references/method.md ========

# The method — principles behind every phase

Distilled (in our own words) from a long public interview with the founder of a leading
naming agency — the firm credited with names such as Swiffer, BlackBerry, Pentium,
Sonos, Febreze, Azure, Impossible and Windsurf. Use these as principles, not scripture;
the anecdotes are there to make the principles memorable.

## Why the name deserves the effort

- **It is the most-used, longest-lived brand asset.** Nothing else in the brand gets used
  as often or for as long, and familiarity compounds every day it's in market. That
  makes getting it right early far cheaper than fixing it later.
- **Right, not just good.** The useful distinction isn't good vs bad but *right* vs
  merely good or okay. A right name creates an asymmetric advantage — most visibly in the
  first 90–120 days and the first year, when attention, retail interest and press are won.
- **Evidence from the field.** P&G wanted to call its new floor tool "Pro Mop" and
  couldn't have it legally. The agency noticed it wasn't really a mop, and that nobody
  enjoys mopping, so they made it fun: Swiffer, which grew into a multi-billion-dollar
  brand. A rival launched around the same time with a comfortable, mop-saying name and
  stayed a fraction of the size. Codium, a coding tool nobody could spell or search for,
  took off after becoming Windsurf.
- **The classic founder mistake:** the lawyer needs a name for incorporation papers, so
  the founders spend an afternoon on it — and later pay again, in time and money, to
  rename.

## The three jobs of a right name

1. **Get attention** — harder now than it has ever been.
2. **Hold attention** — be *processing-fluent*: pronounceable, with something inside
   the brain can grab and understand.
3. **Surprise** — not comfortable, not popular. This is the one most people get wrong,
   and it's why so many names are merely okay.

Right names are therefore **original in their category** (they don't have to be coined —
just new in this context), **linguistically fluent** (familiar yet surprising — the
agency's phrase is *surprisingly familiar*, because the lazy brain welcomes the easy
part and wakes up for the surprising part), and **unexpected** — relative to the company
as much as the category. Azure turned heads coming from Microsoft, whose portfolio was
mostly descriptive; the same word from a company already known for playful names
wouldn't have.

## The comfort trap

Picture two zones. In the **invisible zone**, names are highly familiar and barely
distinctive: lots of consensus, a "safe choice", and nothing remarkable. In the
**tension zone**, half the room dislikes the name; energy is high and opinions split.
Comfortable names do well in naive research because people can instantly say what the
product is — which is exactly why they disappear on the shelf.

Polarization is information. When Intel's engineers wanted a sensible "professional chip"
style name, Andy Grove backed Pentium precisely *because* it was polarizing: a name that
splits the room has energy in it. The agency now tells clients: if this divides your
organization, good — you may not choose it, but study what's creating that energy.

## Strategy before creativity

- **Look at the landscape first** and put everything there into a bucket marked "we're not
  going there". (We may come back, but we start knowing where everyone else already is.)
- **List everything the product has, then look hard at the people**: their needs and
  expectations, climbing the ladder to the *ultimate benefit*. For fiber: past gut health
  and regularity to *you feel lighter* — which is where a name like Feather comes from.
- **Ask the four questions** — How do you define winning? (Put six executives in a room
  and you'll get six answers.) What do you have that helps you win? What do you need to
  win? What do you need to say?
- **Write a creative framework** — deliberately a *window* people can walk through and
  create, rather than five rules to conform to.
- **When there's no magic-bullet feature** (the usual case), the name carries the
  ultimate benefit or an attitude. Impossible's founders wanted something earthy and
  natural that would fit in at a health-food store; the agency argued that fitting in was
  the problem and the name had to make a claim.

## The treasure hunt

- **Map the whole ocean, then dive.** (The gold-ship story: map everything, decide where
  the odds are, then dive.) Explore every territory before committing to one.
- **Quantity leads to quality.** Stuck clients typically show 50–100 names — the point
  where they stopped, and where everyone else stopped too. The agency works through
  around 2,000 per project. Most are "trash", and the trash is necessary.
- **Ask questions, not for names.** The founder uses AI tools to ask about the territory
  (aviation, what makes a plane lift, other words for light → sun → *sol*), then crafts
  names himself.
- **Build enriched databases.** Latin and Greek roots, Greek and Roman mythology, and a
  periodic table loaded with articles and lore (Pentium came out of that) — the riches are
  in the enrichment, not the bare list.
- **File by quality, not category.** Names made for a small car go into a "small things"
  bank next to names made for a small processor. Connecting seemingly irrelevant things —
  *synchronicity* — is, in the founder's view, the fundamental layer of creativity.
- **Two unfamiliar magazines.** Before finishing any creative piece, spend 30 minutes with
  publications you'd never normally read, looking for connections; roughly a third of the
  time it yields a new angle.

## How the teams work

- **No brainstorming sessions, no freelancers.** After 18 months of tracking where names
  actually came from, the agency found they came from individuals and two-person teams.
  Groups bring peer pressure and a slow cascade of evaluation; outsiders lack the
  context and the team spirit.
- **Three teams, three perspectives.** One knows everything about the product. One gets
  the product plus a twist (the fiber *also gives energy*), which changes their angle and
  their names. One isn't told about the product at all and names an analog (athletic
  performance) — three genuinely different lists.
- **Cycles.** The first cycle tests whether the assignments were right: did the twist
  yield anything? the analog? Redial what didn't work. After about two cycles, review
  against the creative framework and send the survivors to legal and linguists.
- **Everyone has permission to fail.** If nobody is failing, nobody is searching the
  whole ocean.

## Encourage, don't evaluate (while generating)

- Lead rather than manage, and *encourage* — the root of the word is courage. People
  only bring risky ideas to someone who won't slap them down.
- When a list arrives, **speculate with it rather than evaluate it**. Evaluation comes
  later and it's real — but it has its own time.
- **Coaching phrases.** "That's interesting." "I wouldn't have thought of that." When you
  feel the urge to say "too expensive" or "won't pass legal", say "I wish we could make
  that cheaper" or "how could we modify that word so it's legally available?" — you've
  handed over a problem instead of a verdict, and people love solving problems.
- **The approximate-thinking line.** Draw a line: bizarre/absurd/illegal ideas at one end,
  safe/workable at the other, *approximate thinking* in the middle. Let teams travel from
  bizarre toward approximate — and stop there to look at what they've got. Permission to
  be approximate makes creativity spike.
- **Separate the rooms** (Disney reputedly kept separate spaces for dreaming, planning and
  judging).

## Judging

- **AI makes generation cheap, so judging is the advantage**: separating right names
  from good and okay ones, using data rather than taste alone.
- **Tools of judgment:** processing fluency and memorability; consonant–vowel rhythm (the
  earliest pattern children produce — ma-ma, da-da); sound symbolism (some sounds read
  fast, some reliable — B tested as one of the most reliable sounds across languages);
  trademark screening by specialists; linguists in every target market.
- **Gut scores with no sevens** force a decision.

## Presenting

- **Proof of concept, not a list.** Show each name in context — a premium black-and-white
  ad, a headline, a shirt, the side of a bus — after first checking internally that it's
  *believable* in the first split second.
- **Supporting copy carries the category** ("Feather — the lightweight fiber you need";
  Swiffer didn't need to say mop because the line around it did).
- **Every famous name was rejected at first.** BlackBerry was dismissed in the first
  meeting. The agency took it off the table *for now* and brought it back with reasons: B
  is one of the most reliable sounds, *black* travels across languages, a berry is
  delightful — and the big competitors would never have the courage to put it on a
  device. That last point turned the room.
- **After the name:** descriptor and positioning line, a short story, nomenclature for
  what comes next, and light tracking research over the first 90–120 days.

## Calibration (the founder's quick gut takes, for flavour only)

SpaceX scored a 10 — the meaning is expected, but X reliably signals innovation.
HubSpot an 8 — memorable rhythm. Grok a 3 or 4 — an unpleasant sound. On X vs Twitter,
he'd have stuck with Twitter. Names he admires: DreamWorks, and Lexus for its structure
(X in the middle again). The best political slogan in his view: Reagan's "Morning in
America" — hope that wasn't false.

## Renaming

See `renaming.md`.


======== FILE: references/renaming.md ========

# Should we rename? And how to launch one

## Principles

- **Names compound.** The longer a name is in market, the more familiarity it banks —
  which is why the cost of fixing a wrong name rises every month.
- **Bad names create friction every day**: misspellings, failed searches, confusion
  with others, the need to explain. That cost is quiet but permanent.
- **Fear of losing momentum is usually overstated.** The agency says it has never seen
  evidence of a rename losing equity or momentum *when the launch is done with
  enthusiasm and a clear story*, and customers understand they're not losing the
  product they rely on.
- **Stage matters.** For a young company (roughly seed to Series B), a rename is a
  focused 6–9 month effort, not a crisis. For a giant, long-established brand, it needs
  a compelling reason.
- **Legal threat makes it simple.** If you're being sued or can't register the mark,
  the decision is made for you.
- **Commitment matters.** A rename forced on owners who privately want to keep the name
  tends to fail. If the founders aren't open to it, explore the case with them first
  rather than starting a project.

## Assessment (do this before any naming work)

1. **Score the current name** on `evaluation.md`, honestly, and place it in a zone.
2. **Gather friction evidence:** misspellings in search queries and support tickets,
   typed-URL errors, confusion with other companies, how often the team has to explain
   it, how findable it is in search, trademark or legal exposure, and whether it fits
   where the company is going (new products, new markets).
3. **Estimate equity:** how much recognition exists (customers, search volume, press,
   partners) and how much of it is tied to the name versus the product.
4. **Stage and cost:** company stage, number of touchpoints (domains, apps, contracts,
   signage, packaging), and who has to be told.
5. **Recommend one of three:**
   - **Rename** — friction is real and growing, equity is modest or portable.
   - **Keep and support** — the name is okay but under-explained; add a descriptor or
     positioning line that carries the category.
   - **Keep** — the name works; the problem is elsewhere.

Put the recommendation to the user with the evidence, and let them decide.

## The launch story (if renaming)

A rename is a story, not an announcement. Structure:

1. **Where we were** — what the old name stood for, with respect.
2. **Why we're changing** — where the company is going.
3. **What stays the same** — the product, the people, the data, the commitments.
4. **What's new for you** — the concrete benefits (A, B, C).
5. **The new name and what it says.**

Transition checklist: secure domains and handles first; redirects from every old URL;
app-store listings; legal entity and contracts; payment descriptors; email domains;
social profiles; a "formerly <old name>" period of 6–12 months in search snippets,
signatures and descriptions; an internal launch before the external one.


======== FILE: references/sound-symbolism.md ========

# Sound symbolism and processing fluency

These are tendencies from sound-symbolism research (bouba/kiki, mil/mal-style studies,
brand-name experiments) and from naming-agency practice. They are probabilities, not
laws. Use them to **steer** a promising name toward the desired feel and to **break
ties** — never to veto a name that has meaning and energy.

## Processing fluency

- **Consonant–vowel rhythm** (CVCV…) is the earliest pattern children produce (ma-ma,
  da-da) and travels easily across languages: Sonos, Toyota, Lego, Nokia.
- **Two or three syllables** is the sweet spot. One syllable works best when it's a real
  word; four or more needs a strong rhythm (Im-pos-si-ble works because it's a word).
- **Clusters** of three or more consonants slow non-native speakers.
- **Real words and familiar morphemes** process fastest. Let the surprise come from the
  context, not from difficulty.
- **Hear it, spell it.** Avoid spellings with several options for one sound (c/k, ph/f,
  ee/ea/ie, y/i) unless the word is already known. Every respelling taxes word of mouth
  and search.
- **Repetition and echo** (Sonos, Coca-Cola, Kit Kat) help memory.

## What sounds tend to signal

| Sounds | Tends to feel | Notes |
|---|---|---|
| Voiceless stops **p, t, k** | fast, sharp, precise, small | Punchy openers; K reads powerful |
| Voiced stops **b, d, g** | sturdy, reliable, bigger | The agency found **B** one of the most reliable sounds across languages (BlackBerry) |
| **z**, **x** | speed, edge, energy | **X** reliably signals innovation/tech (SpaceX, Lexus, Xeon) — so it's surprising only outside tech |
| Fricatives **f, v, s, sh, h, th** | airy, smooth, soft, light, fresh | Lightness and freshness: Feather, Febreze, Swiffer |
| Nasals **m, n** | warm, comforting, human | m recalls comfort and care |
| Liquids **l, r** | flowing, smooth, gentle | l feels light; r adds movement |
| Front vowels **i** (bee), **e** | small, light, quick, bright | "mil" is judged smaller than "mal" |
| Back/open vowels **o, u, a** | big, round, heavy, slow, warm, deep | "bouba" is round, "kiki" is spiky |

## Matching a desired feel

- **Fast / agile:** voiceless stops, z, x, front vowels, short words.
- **Reliable / solid:** b, d, g, k, balanced CV rhythm, back vowels.
- **Light / fresh:** f, s, sh, l, front vowels, open endings.
- **Warm / human:** m, n, l, open vowels, soft endings.
- **Premium / calm:** fewer stops, longer vowels, liquids and nasals.

## Using the script

```
python <skill-dir>/scripts/name_tools.py phonetics Feather Updraft Pentium --profile light fast
python <skill-dir>/scripts/name_tools.py phonetics --from shortlist.json --profile reliable warm
```

Profile words it understands include: fast, quick, light, fresh, sharp, crisp, strong,
bold, reliable, trusted, solid, big, premium, smooth, soft, calm, elegant, warm, friendly,
human, edgy, innovative, modern.

It reports syllables, the C/V pattern, alternation (1.0 = perfect CVCV), the longest
consonant cluster, spelling traps, a structural *ease* score, the strongest *feels*, and
*fit* against the requested profile. It reads spelling, not sound — always say the name
out loud before trusting a number.


======== FILE: references/territories.md ========

# Where names come from: territories, types and moves

## Territory families

Each territory yields **word-stock** (roots, terms, facts, idioms), not finished names.
The Cartographer charts 30–50 territories across these families; the teams dig into
their share.

1. **The ultimate benefit and its metaphors** — lightness → air, feathers, lift,
   floating, sky, bubbles.
2. **Mechanism and science** — the physics, biology, chemistry or craft behind the
   benefit (aerodynamics for lift; fermentation for gut health).
3. **Classical roots** — Greek and Latin words for the core ideas; combine, truncate,
   re-suffix. Pentium drew on *pent-* (five) and the feel of an element name.
4. **Mythology and legend** — Greek, Roman, Norse, Egyptian, African, Asian and other
   traditions: figures, objects, places. Check the full story; some carry baggage.
5. **The periodic table and its lore** — elements, discoverers, Latin names, properties.
6. **Nature** — animals, plants, fruit, weather, sky, sea, geology (BlackBerry, Azure,
   Toro).
7. **The language of the feeling** — idioms, compliments, everyday expressions for the
   state you want people in ("I feel light").
8. **The sound or verb of the action** — onomatopoeia, motion verbs (Swiffer).
9. **Claims and attitudes** — words that make a promise or take a stance (Impossible).
10. **Crafts and trades** — tools, techniques and jargon of skilled work.
11. **Places and local language** — landscapes, local words, landmarks of the target
    markets. (Pure place names can be hard to protect.)
12. **Exploration, navigation, astronomy** — instruments, maps, stars, routes.
13. **Music, art, architecture, design** — terms, instruments, movements.
14. **Far domains (sparks)** — fields chosen at random with `name_tools.py sparks`;
    the home of synchronicity.
15. **Analog categories** — other industries that share the ultimate benefit (Team C).
16. **The vault** — names from past projects filed by abstract quality (small, fast,
    light, reliable, warm, bold…).

## Name types (from most to least descriptive)

| Type | Examples | Trade-off |
|---|---|---|
| Descriptive | Fiber One, Ready Mop | Instantly clear; usually invisible and hard to protect |
| Suggestive | Benefiber | Hints at the benefit; often crowded |
| Real word, new context | Feather, BlackBerry, Azure, Impossible, Windsurf | Fluent *and* surprising; often the sweet spot; watch search crowding |
| Compound | DreamWorks, HubSpot, SpaceX | Memorable rhythm; can feel generic if both halves are |
| Blend / portmanteau | (two words fused) | Can be clever; can be unpronounceable |
| Coined from roots or sound | Pentium, Febreze, Sonos, Lexus | Most ownable; needs to feel familiar or it becomes noise |
| Initials / acronym | — | Rarely right for a new brand; little to grasp |
| Founder or person name | — | Personal; transfers poorly if the founder leaves |

## Moves for turning word-stock into names

- Put a real word into a new context.
- Collide two words (compound) or fuse them (blend).
- Truncate, extend or re-suffix a word.
- Build from roots; coin a word that sounds like it means something.
- Play with sound: CV rhythm, repetition, plosives, a deliberate X or Z.
- Name the sound or the verb of the action.
- Make a claim.
- Borrow from another language (check meaning in every market).
- Respell — sparingly; each respelling costs spelling-from-hearing.
- Pair a bold name with a descriptor that carries the category.
What it does

business-naming runs a naming project the way a professional naming agency describes its process. It does not stop at a list of names. It writes a short creative strategy and sends three independent teams to generate names from different angles: insiders, a "twist" team and outsiders who never see the real product. A separate judge, who didn't make any of the names, judges them. Shortlisted names go through preliminary language and trademark screens, and the finalists are shown on a visual board in realistic context (headline, ad line, descriptor).
It writes its working files to a naming-<slug>/ project folder, so you can see every stage, from research to the final board and report.
When to reach for it

Reach for it whenever you need a name for a company, product, app, feature or service, or you're stuck choosing between names you already have. You don't need to call it by name. "What should I call this?" is enough.
It also covers three smaller jobs:
Judging names you already have. It skips generation and goes straight to scoring, screening and the board.
Deciding whether to rename. It starts by testing whether a rename is worth it.
A descriptor or tagline for a name you've already chosen.
Say "quick" if you want a faster run with smaller quotas.
It is not for naming variables, files or other code identifiers.
It's working if

The strategy checkpoint makes you disagree with something. That's the cheapest moment to redirect.
The finalists include a few names that make you a little nervous. A set nobody objects to is usually forgettable.
You can see why each finalist was chosen, and which names were set aside rather than thrown away.
The report says plainly that trademark and domain checks are preliminary.
Common questions

Are the trademark checks legal clearance?
No. They're knockout screens to catch obvious conflicts early. Before spending money on a name, have an IP attorney clear it in each market you care about.
Why so many names?
A long list is cheap now. The value is in generating far past the obvious names and then judging strictly in a separate step. Most of the names are meant to be discarded.
I hate one of the finalists. Should I ask for it to be removed?
Say what bothers you. The skill turns objections into a brief ("less clinical", "easier to spell") and can run a small targeted round. Strong names that get rejected are moved off the table for now, not deleted.
Does it need subagents?
It runs best with them, because the teams and the judge are meant to be independent. Without subagents it plays each role in sequence and keeps generating and judging as separate steps.
Where it fits

Use it after you know what you're building. If you're still deciding what the product is, start with hit-products, then come back to name the winner.
Credit: inspired by David Placek's appearance in this video.
Source: github.com/alikibao/public-skills/skills/branding/business-naming