namer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Namer

命名工具Namer

Generate, evaluate, and validate names across linguistic, technical, and platform dimensions. Produces ranked options with availability matrices and actionable next steps.

Not for domain registration, branding strategy, or logo design. Not for reviewing naming conventions in existing code.

跨语言、技术和平台维度生成、评估并验证名称。生成带可用性矩阵和可执行后续步骤的排名选项。

不适用于域名注册、品牌战略或logo设计。也不适用于审查现有代码中的命名规范。

Dispatch

命令调度

$ARGUMENTS	Action
`<thing to name>` (with optional flags)	Name — full pipeline: brief → generate → filter → check → score → rank
`check <name> [name2...]`	Check — availability audit only (skip generation)
`expand <name>`	Expand — generate variations/modifications of an existing name
`compare <name1> vs <name2> [vs...]`	Compare — side-by-side scoring of specific names
`resume [# or keyword]`	Resume — load prior naming session
`list`	List — show saved naming sessions
`preferences`	Preferences — show accumulated naming profile and memory stats
Empty	Gallery — show examples + "what are you naming?" prompt

$ARGUMENTS	操作
`<待命名对象>` （可带可选参数）	命名 — 完整流程：需求梳理 → 生成 → 过滤 → 检查 → 评分 → 排名
`check <name> [name2...]`	检查 — 仅进行可用性审核（跳过生成步骤）
`expand <name>`	拓展 — 生成已有名称的变体/修改版本
`compare <name1> vs <name2> [vs...]`	对比 — 对指定名称进行并列评分
`resume [# or keyword]`	恢复 — 加载之前的命名会话
`list`	列表 — 显示已保存的命名会话
`preferences`	偏好设置 — 显示累计的命名配置文件和记忆统计数据
无参数	示例库 — 展示示例 + "你要命名什么？" 的提示

Gallery (Empty Arguments)

示例库（无参数时）

#	Context	Example
1	CLI Tool	"I'm building a terminal file manager in Rust"
2	SaaS Product	"Developer productivity tool for code review"
3	OSS Library	"Python library for data validation"
4	Startup	"AI-powered hiring platform"
5	Side Project	"Weekend project — a bookmark manager"
6	Brand	"Design agency specializing in developer tools"

Pick a number, describe what you're naming, or type "guide me".

序号	场景	示例
1	CLI Tool	"我正在用Rust开发一款终端文件管理器"
2	SaaS Product	"用于代码评审的开发者生产力工具"
3	OSS Library	"用于数据验证的Python库"
4	Startup	"AI驱动的招聘平台"
5	Side Project	"周末项目——一款书签管理器"
6	Brand	"专注于开发者工具的设计机构"

选择序号、描述你要命名的对象，或输入"guide me"（引导我）。

Guided Intake

引导式信息采集

If the user types "guide me", ask three questions:

What are you naming? "A CLI tool, a SaaS product, an OSS library, a startup, a brand, or something else?"
What does it do? "Describe it in one sentence."
What vibe? "Playful, serious, technical, warm, edgy, minimal, or describe your own."

如果用户输入"guide me"，请询问以下三个问题：

你要命名什么？ "是CLI Tool、SaaS Product、OSS Library、初创企业、品牌，还是其他类型？"
它的功能是什么？ "用一句话描述。"
风格倾向？ "活泼、严肃、技术感、温暖、前卫、极简，或者描述你自己想要的风格。"

Dynamic Context Classification

动态场景分类

Auto-detect from the user's description. Adjusts both platform priority AND scoring weights.

Context Signal	Category	Primary Platforms	Secondary
"CLI tool", "command", "binary"	CLI Tool	GitHub, npm/PyPI/Crates, Homebrew, .dev	Social
"package", "library", "framework", "SDK"	OSS Library	GitHub, npm/PyPI/Crates, .dev/.io	Social
"app", "product", "startup", "SaaS"	Product	.com, X/Twitter, LinkedIn, GitHub	Dev registries
"company", "brand", "agency", "studio"	Brand	.com, X/Twitter, Instagram, LinkedIn, YouTube	Dev registries
"game", "content", "media", "community"	Creative	.com, YouTube, TikTok, X/Twitter, Reddit, Discord	Dev registries
"open source", "OSS", "contrib"	OSS Project	GitHub, npm/PyPI/Crates, .dev, Discord	Social
Ambiguous	Balanced	.com, GitHub, X/Twitter, npm/PyPI	All others

Scoring presets — each context uses different intrinsic/extrinsic dimension weights AND a different intrinsic/extrinsic split ratio. See

references/scoring-rubric.md

§ Context Presets for the full weight tables. Key differences:

CLI Tool: 30/70 intrinsic/extrinsic split — typeability (30%) and registry (35%) dominate extrinsic
Brand: 50/50 split — phonetics (30%) and domain (35%) are top priorities
Side Project: 25/75 split — availability-first; typeability (40%) and registry (20%) lead extrinsic

Present the classification and preset to the user. User can override with

--style

or adjust weights manually.

根据用户描述自动识别。同时调整平台优先级和评分权重。

场景信号	分类	核心平台	次要平台
"CLI tool"、"command"、"binary"	CLI Tool	GitHub、npm/PyPI/Crates、Homebrew、.dev	社交平台
"package"、"library"、"framework"、"SDK"	OSS Library	GitHub、npm/PyPI/Crates、.dev/.io	社交平台
"app"、"product"、"startup"、"SaaS"	Product	.com、X/Twitter、LinkedIn、GitHub	开发者注册平台
"company"、"brand"、"agency"、"studio"	Brand	.com、X/Twitter、Instagram、LinkedIn、YouTube	开发者注册平台
"game"、"content"、"media"、"community"	Creative	.com、YouTube、TikTok、X/Twitter、Reddit、Discord	开发者注册平台
"open source"、"OSS"、"contrib"	OSS Project	GitHub、npm/PyPI/Crates、.dev、Discord	社交平台
模糊描述	均衡型	.com、GitHub、X/Twitter、npm/PyPI	其他所有平台

评分预设 — 每个场景使用不同的内在/外在维度权重，以及不同的内在/外在占比。完整权重表请查看

references/scoring-rubric.md

的「场景预设」章节。核心差异：

CLI Tool：内在/外在占比30/70 — 易输入性（30%）和注册平台可用性（35%）在外部因素中占主导
Brand：占比50/50 — 语音特性（30%）和域名可用性（35%）是首要优先级
Side Project：占比25/75 — 可用性优先；易输入性（40%）和注册平台可用性（20%）在外部因素中占主导

向用户展示分类结果和预设。用户可通过

--style

参数覆盖预设，或手动调整权重。

Core Workflow (6 Phases)

核心工作流程（6个阶段）

Phase -1: Memory Load (runs once per session)

阶段-1：记忆加载（每个会话运行一次）

!uv run python scripts/memory.py load

If memory exists, integrate into session:

Archetype affinities → bias Phase 1 generation distribution (e.g., 35% evocative if user favors it)
Phonetic likes/dislikes → add to Phase 1 hard filters (dislikes) and soft scoring boosts (likes)
Length preferences → adjust length constraints in Phase 1
Weight overrides → pre-fill Phase 3 scoring weights
Context defaults → suggest context in Phase 0 Brief ("Last time you named a CLI tool — same context?")
Inspirations → reference in Phase 1 generation as stylistic anchors
Past selections → avoid regenerating names the user already picked

If no memory exists, proceed normally. Memory is additive — never block a phase on missing memory.

!uv run python scripts/memory.py load

如果存在记忆数据，将其整合到会话中：

原型偏好 → 影响阶段1的生成分布（例如，如果用户偏好唤起型名称，则分配35%的生成比例）
语音喜好/厌恶 → 添加到阶段1的硬过滤规则（厌恶项）和软评分加分项（喜好项）
长度偏好 → 调整阶段1的长度限制
权重覆盖 → 预填充阶段3的评分权重
默认场景 → 在阶段0的需求梳理中建议场景（"上次你为CLI Tool命名——是否使用相同场景？"）
灵感参考 → 在阶段1生成时作为风格锚点参考
过往选择 → 避免重新生成用户已选过的名称

如果没有记忆数据，正常进行流程。记忆是累加式的——永远不要因缺少记忆数据而阻塞某个阶段。

Phase 0: Brief (sequential, interactive)

阶段0：需求梳理（顺序式、交互式）

Parse what's being named, context, constraints
Auto-classify naming context → select preset
Present classification + adjusted weights to user
Accept overrides:
```
--style
```
,
```
--thorough
```
, manual weight adjustment
Accept inspirations: "I like names like Vercel, Stripe, Neon"

解析待命名对象、场景和约束条件
自动分类命名场景 → 选择预设
向用户展示分类结果和调整后的权重
接受覆盖参数：
```
--style
```
、
```
--thorough
```
，以及手动权重调整
接受灵感参考："我喜欢Vercel、Stripe、Neon这类名称"

Phase 1: Generate & Filter (inline, single-pass)

阶段1：生成与过滤（内联、单次执行）

Load

references/naming-strategies.md

for archetype details and sound symbolism guide.

Generate 40-60 candidates across 6 naming archetypes:

Archetype	Description	Examples
Invented words	Phonetically constructed neologisms	Kodak, Xerox, Hulu, Roku
Metaphorical transfers	Concepts from other domains	Amazon, Safari, Slack, Rust
Compound blends	Portmanteaus, morpheme combos	Instagram, Pinterest, YouTube
Classical roots	Latin, Greek, Sanskrit etymology	Nike, Astra, Veritas, Lumen
Evocative fragments	Short, punchy, abstract feel	Figma, Sumo, Neon, Zed
Descriptive-creative	Clear meaning with flair	Cloudflare, Datadog, Fastly

Hard filters (binary pass/fail, run BEFORE availability checking):

Run

!uv run python scripts/generate.py filter --input candidates.json

for automated filters, then apply AI-only filters inline:

Profanity/vulgarity in English (script:
```
generate.py filter
```
)
Offensive meaning in top 10 world languages (AI-only: use
```
brave_web_search
```
)
Exact collision with top-1000 brand in same category (AI-only: use
```
brave_web_search
```
)
Exceeds length limit (15 chars product, 8 chars CLI, 12 chars library) (script:
```
generate.py filter
```
)
Unpronounceable consonant clusters (script:
```
generate.py filter
```
)
Reserved word in major programming languages (script:
```
generate.py filter
```
)
Contains hyphens/special chars (for package names) (script:
```
generate.py filter
```
)

Score intrinsic dimensions (phonetics, semantics, memorability, morphological flexibility, visual quality). Use

!uv run python scripts/generate.py analyze <name>

for phonetic breakdown to inform phonetic quality scoring. Select top 20-25 for availability checking.

--thorough

mode: Run multiple generation passes with varied prompting for more diversity.

加载

references/naming-strategies.md

以获取原型细节和语音象征指南。

跨6种命名原型生成40-60个候选名称：

命名原型	描述	示例
自创词汇	基于语音构造的新词	Kodak、Xerox、Hulu、Roku
隐喻迁移	源自其他领域的概念	Amazon、Safari、Slack、Rust
复合融合	混成词、语素组合	Instagram、Pinterest、YouTube
古典词根	拉丁语、希腊语、梵语词源	Nike、Astra、Veritas、Lumen
唤起型片段	简短有力、抽象感强	Figma、Sumo、Neon、Zed
描述创意型	含义清晰且富有创意	Cloudflare、Datadog、Fastly

硬过滤规则（二元通过/失败，在可用性检查前执行）：

运行

!uv run python scripts/generate.py filter --input candidates.json

执行自动化过滤，然后内联应用仅AI可处理的过滤规则：

英文脏话/低俗词汇（脚本：
```
generate.py filter
```
）
在全球前10大语言中有冒犯性含义（仅AI处理：使用
```
brave_web_search
```
）
与同类别前1000品牌完全重名（仅AI处理：使用
```
brave_web_search
```
）
超过长度限制（产品名15字符，CLI工具名8字符，库名12字符）（脚本：
```
generate.py filter
```
）
存在无法发音的辅音组合（脚本：
```
generate.py filter
```
）
属于主流编程语言的保留字（脚本：
```
generate.py filter
```
）
包含连字符/特殊字符（针对软件包名称）（脚本：
```
generate.py filter
```
）

对内在维度（语音特性、语义、易记性、形态灵活性、视觉效果）进行评分。使用

!uv run python scripts/generate.py analyze <name>

进行语音分析，为语音质量评分提供依据。选出排名前20-25的候选名称进行可用性检查。

--thorough

模式：通过多样化提示词运行多轮生成，以获得更多样化的结果。

Phase 2: Availability Sweep (parallel subagents)

阶段2：可用性扫描（并行子代理）

Load

references/platform-checks.md

for per-platform check methods.

Dispatch 4 parallel subagents, each checking ALL candidates in its category:

Subagent A — Domain Checker:

.com/.net via RDAP:

GET https://rdap.verisign.com/com/v1/domain/{name}.com

→ 404 = available

.dev/.io/.ai/.app via brave_web_search
Pricing: brave_web_search for top 5 candidates

Subagent B — Dev Registry Checker (Direct API):

GitHub:
```
GET https://api.github.com/users/{name}
```
→ 404 = available
npm:
```
GET https://registry.npmjs.org/{name}
```
→ 404 = available
PyPI:
```
GET https://pypi.org/pypi/{name}/json
```
→ 404 = available

Crates:

GET https://crates.io/api/v1/crates/{name}

→ 404 = available

Subagent C — Social & Handle Checker:

Reddit:

GET https://www.reddit.com/api/username_available.json?user={name}

Bluesky: AT Protocol handle resolution
X/Twitter, YouTube, Instagram, LinkedIn: brave_web_search with
```
site:
```
prefix

Subagent D — Conflict & Distinctiveness:

Search collision volume:
```
brave_web_search '"{name}" software'
```
Trademark (--thorough):
```
brave_web_search "USPTO TESS {name}"
```

Or run deterministic checks via script:

!uv run python scripts/availability.py check-all candidate1 candidate2 ...

Scaling:

≤10 candidates: 4 parallel subagents
11-25 candidates: Pre-filter with quick .com RDAP, full check top 10-15
```
--thorough
```
: All social + trademark + Wikipedia checks

加载

references/platform-checks.md

以获取各平台的检查方法。

调度4个并行子代理，每个子代理检查其负责类别下的所有候选名称：

子代理A — 域名检查器：

.com/.net域名通过RDAP检查：
```
GET https://rdap.verisign.com/com/v1/domain/{name}.com
```
→ 返回404表示可用
.dev/.io/.ai/.app域名通过
```
brave_web_search
```
检查
价格信息：通过
```
brave_web_search
```
查询排名前5的候选域名价格

子代理B — 开发者注册平台检查器（直接API调用）：

GitHub：
```
GET https://api.github.com/users/{name}
```
→ 返回404表示可用
npm：
```
GET https://registry.npmjs.org/{name}
```
→ 返回404表示可用
PyPI：
```
GET https://pypi.org/pypi/{name}/json
```
→ 返回404表示可用

Crates：

GET https://crates.io/api/v1/crates/{name}

→ 返回404表示可用

子代理C — 社交平台账号检查器：

Reddit：

GET https://www.reddit.com/api/username_available.json?user={name}

Bluesky：通过AT协议解析账号可用性
X/Twitter、YouTube、Instagram、LinkedIn：使用带
```
site:
```
前缀的
```
brave_web_search
```
检查

子代理D — 冲突与独特性检查器：

搜索冲突量：
```
brave_web_search '"{name}" software'
```
商标检查（--thorough模式）：
```
brave_web_search "USPTO TESS {name}"
```

也可通过脚本执行确定性检查：

!uv run python scripts/availability.py check-all candidate1 candidate2 ...

扩展策略：

≤10个候选名称：使用4个并行子代理
11-25个候选名称：先通过快速.com RDAP检查预过滤，对排名前10-15的名称进行完整检查
```
--thorough
```
模式：检查所有社交平台+商标+维基百科

Phase 2.5: Variant Generation (conditional)

阶段2.5：变体生成（条件触发）

For top 5 intrinsic-scored candidates that FAILED availability:

Generate 3-5 variants each: prefix (
```
go-
```
,
```
un-
```
), suffix (
```
-kit
```
,
```
-lab
```
,
```
-ify
```
), vowel dropping (
```
namr
```
), respelling (
```
nomer
```
), scoped (
```
@scope/name
```
)
Run availability checks on variants (same subagent pattern, smaller batch)

针对内在评分排名前5但可用性检查未通过的候选名称：

为每个名称生成3-5个变体：前缀（
```
go-
```
、
```
un-
```
）、后缀（
```
-kit
```
、
```
-lab
```
、
```
-ify
```
）、元音省略（
```
namr
```
）、重拼写（
```
nomer
```
）、作用域限定（
```
@scope/name
```
）
对变体进行可用性检查（使用相同的子代理模式，批次更小）

Phase 3: Score & Rank (inline)

阶段3：评分与排名（内联执行）

Load

references/scoring-rubric.md

for detailed criteria.

10 scoring dimensions (0-10 scale, context-weighted):

Dimension	Method
Domain availability	.com=10, .dev/.io=7, .ai/.app=5, parked=3, none=0
Registry availability	% of target registries available
Handle consistency	% of target social platforms available
Memorability	Length bonus + syllable count + imagery
Phonetic quality	Consonant/vowel flow, stress, sound symbolism
Semantic fit	Domain relevance, emotional tone, metaphor richness
Typeability	Character count, keyboard locality, no specials
Search distinctiveness	Inverse of search result count
Morphological flexibility	Can verb/noun/compound? Product family support?
Visual quality	Letter balance, ascenders/descenders, URL aesthetics

Composite:

(0.4 × intrinsic_avg) + (0.6 × extrinsic_avg)

— user can adjust split.

Run

!uv run python scripts/score.py score --input candidates.json

for deterministic scoring. Input JSON must have

{"candidates": [{"name": "...", "intrinsic": {...}, "availability": {...}}], "preset": "cli-tool"}

加载

references/scoring-rubric.md

以获取详细评分标准。

10个评分维度（0-10分，按场景加权）：

维度	评分方法
域名可用性	.com=10分，.dev/.io=7分，.ai/.app=5分，已停放=3分，无可用=0分
注册平台可用性	目标注册平台的可用占比
社交账号一致性	目标社交平台的可用占比
易记性	长度加分 + 音节数 + 意象关联
语音质量	辅音/元音流畅度、重音、语音象征
语义契合度	领域相关性、情感基调、隐喻丰富度
易输入性	字符数、键盘按键位置、无特殊字符
搜索独特性	搜索结果数量的倒数
形态灵活性	是否可作为动词/名词/复合词？是否支持产品系列命名？
视觉效果	字母平衡度、升降笔画、URL美观度

综合评分：

(0.4 × 内在平均分) + (0.6 × 外在平均分)

— 用户可调整该占比。

运行

!uv run python scripts/score.py score --input candidates.json

执行确定性评分。输入JSON必须包含

{"candidates": [{"name": "...", "intrinsic": {...}, "availability": {...}}], "preset": "cli-tool"}

结构。

Phase 4: Present (inline)

阶段4：结果展示（内联执行）

Load

references/output-formats.md

for templates.

Three ranked views:

Best Names — ranked by intrinsic quality (availability shown but not factored)
Best Available — ranked by composite score (default recommendation)
Best with Variants — top intrinsic names with available modifications

Each view: ranked table with availability matrix (✅ ❌ ⚠️ ❓), scores, rationale.

Detailed cards for top 3 per view: full scoring breakdown, strengths, risks, next steps.

Actionable next steps: "Register neon.dev at $12/yr", "Claim @neon on GitHub", "

npm init neon

Interactive refinement: "more like #3", "shorter", "more technical", "avoid X sounds"

Dashboard: After all views and cards are produced, assemble the full session into the JSON schema from

references/output-formats.md § Structured Output Schema

. Read

templates/dashboard.html

, replace

{}

<script id="data" type="application/json">{}</script>

with the JSON, and write the result to

~/.{gemini|copilot|codex|claude}/namer/{session-slug}-dashboard.html

. Print the open command:

open ~/.{gemini|copilot|codex|claude}/namer/{slug}-dashboard.html

加载

references/output-formats.md

以获取展示模板。

三种排名视图：

最佳名称 — 按内在质量排名（显示可用性但不纳入排名依据）
最佳可用名称 — 按综合评分排名（默认推荐）
最佳变体名称 — 内在质量排名靠前的名称及其可用变体

每个视图：包含可用性矩阵（✅ ❌ ⚠️ ❓）、评分和依据的排名表格。

每个视图排名前3的名称提供详细卡片：完整评分 breakdown、优势、风险、后续步骤。

可执行后续步骤："以每年12美元注册neon.dev"、"在GitHub上认领@neon账号"、"

npm init neon

交互式优化："多生成类似#3的名称"、"更短"、"更具技术感"、"避免X音"

仪表盘：生成所有视图和卡片后，将整个会话内容组装为

references/output-formats.md

「结构化输出Schema」中的JSON格式。读取

templates/dashboard.html

，将

<script id="data" type="application/json">{}</script>

中的

{}

替换为该JSON，然后将结果写入

~/.{gemini|copilot|codex|claude}/namer/{session-slug}-dashboard.html

。打印打开命令：

open ~/.{gemini|copilot|codex|claude}/namer/{slug}-dashboard.html

Save Session

保存会话

Save to

~/.{gemini|copilot|codex|claude}/namer/{YYYY-MM-DD}-{context}-{slug}.md

with YAML frontmatter after Phase 1 (candidates), Phase 2 (availability), Phase 4 (ranking). Supports resume.

在阶段1（生成候选名称）、阶段2（可用性检查）、阶段4（排名）完成后，将会话保存到

~/.{gemini|copilot|codex|claude}/namer/{YYYY-MM-DD}-{context}-{slug}.md

，文件包含YAML前置信息。支持恢复会话。

Memory Save Triggers

记忆保存触发条件

Save memories at natural decision points. NEVER slow down a phase for a memory write — always save AFTER delivering primary output.

Trigger	Command
Phase 0: User states style preference	`memory.py save-preference --type vibe --value "..."`
Phase 0: User cites inspiration names	`memory.py save-inspiration --name "..." --context "..."`
Phase 0: User adjusts weights	`memory.py save-weights --intrinsic-split F --extrinsic-split F`
Phase 1: User says "avoid X sounds"	`memory.py save-rejection --pattern "X" --type phonetic --reason "..."`
Phase 4: User selects a name	`memory.py save-selection --name "..." --archetype "..." --context "..." --score N --query "..."`
Refinement: "more like #N"	`memory.py save-preference --type archetype --value "..." --like`
Refinement: "shorter" / "longer"	`memory.py save-preference --type length --value "max=5"` or `"min=8"`
Any: User rejects a style	`memory.py save-rejection --pattern "..." --type archetype --reason "..."`

Batch multiple saves in a SINGLE message when a session produces several memories. All

memory.py

commands are prefixed with

!uv run python scripts/

在自然决策节点保存记忆数据。永远不要因写入记忆数据而减慢某个阶段的速度——务必在交付核心输出后再保存。

触发条件	命令
阶段0：用户说明风格偏好	`memory.py save-preference --type vibe --value "..."`
阶段0：用户提及灵感名称	`memory.py save-inspiration --name "..." --context "..."`
阶段0：用户调整权重	`memory.py save-weights --intrinsic-split F --extrinsic-split F`
阶段1：用户说"避免X音"	`memory.py save-rejection --pattern "X" --type phonetic --reason "..."`
阶段4：用户选择某个名称	`memory.py save-selection --name "..." --archetype "..." --context "..." --score N --query "..."`
优化请求："多生成类似#N的名称"	`memory.py save-preference --type archetype --value "..." --like`
优化请求："更短"/"更长"	`memory.py save-preference --type length --value "max=5"` 或 `"min=8"`
任意场景：用户拒绝某种风格	`memory.py save-rejection --pattern "..." --type archetype --reason "..."`

当一个会话产生多个记忆数据时，将多个保存命令合并为一条消息发送。所有

memory.py

命令均需添加前缀

!uv run python scripts/

。

Canonical Vocabulary

标准术语表

Term	Definition
brief	Naming requirements: what, context, style, constraints
candidate	A generated name before availability checking
archetype	Naming strategy: invented, metaphorical, compound, classical, evocative, descriptive
intrinsic score	Quality from linguistic/creative dimensions (no I/O)
extrinsic score	Availability from platform checks (I/O intensive)
composite score	Weighted combination of intrinsic + extrinsic
hard filter	Binary pass/fail gate: profanity, length, pronounceability
variant	Modification of a candidate: prefix, suffix, respelling
namespace report	Per-candidate availability matrix across all platforms
context preset	Auto-configured weights + platforms for what's being named
memory	Persistent naming preferences at `~/.{gemini
archetype affinity	Weighted distribution of user's preferred naming archetypes, computed from selections
selection	A name the user chose as their winner, stored for preference learning
rejection	An explicitly unwanted pattern (phonetic, archetype, or specific name)

术语	定义
brief（需求梳理）	命名需求：待命名对象、场景、风格、约束条件
candidate（候选名称）	可用性检查前生成的名称
archetype（命名原型）	命名策略：自创、隐喻、复合、古典、唤起型、描述创意型
intrinsic score（内在评分）	从语言/创意维度评估的质量（无需输入输出操作）
extrinsic score（外在评分）	从平台可用性检查得到的结果（需大量输入输出操作）
composite score（综合评分）	内在评分与外在评分的加权组合
hard filter（硬过滤）	二元通过/失败规则：脏话、长度、可发音性
variant（变体）	候选名称的修改版本：前缀、后缀、重拼写
namespace report（命名空间报告）	每个候选名称在所有平台上的可用性矩阵
context preset（场景预设）	根据待命名对象自动配置的权重和平台列表
memory（记忆数据）	持久化的命名偏好，存储于`~/.{gemini
archetype affinity（原型偏好）	根据用户过往选择计算出的、用户偏好的命名原型权重分布
selection（选中名称）	用户选定的最终名称，用于偏好学习
rejection（拒绝项）	用户明确表示不想要的模式（语音、原型或特定名称）

Reference File Index

参考文件索引

File	Content	Read When
`references/naming-strategies.md`	6 archetypes, sound symbolism, phonetic guide, morpheme library	Phase 1 (generation)
`references/platform-checks.md`	Per-platform: URLs, methods, response parsing, rate limits	Phase 2 (availability)
`references/scoring-rubric.md`	10 dimensions detailed, 6 presets, hard filters, composite formula	Phase 3 (scoring)
`references/output-formats.md`	Templates for 3 views, name cards, variant tables, next-steps	Phase 4 (presentation)
`templates/dashboard.html`	Self-contained GUI — inject structured JSON from § Structured Output Schema	Phase 4 (dashboard render)
`scripts/memory.py`	CLI for persistent naming preferences (load, save, prune, stats)	Phase -1 (load), end of session (save)

Load ONE reference at a time per the "Read When" column.

文件	内容	读取时机
`references/naming-strategies.md`	6种命名原型、语音象征、语音指南、语素库	阶段1（生成）
`references/platform-checks.md`	各平台详情：URL、方法、响应解析、速率限制	阶段2（可用性检查）
`references/scoring-rubric.md`	10个维度的详细说明、6种场景预设、硬过滤规则、综合评分公式	阶段3（评分）
`references/output-formats.md`	3种视图、名称卡片、变体表格、后续步骤的模板	阶段4（结果展示）
`templates/dashboard.html`	独立GUI界面——注入「结构化输出Schema」章节中的结构化JSON	阶段4（仪表盘渲染）
`scripts/memory.py`	用于持久化命名偏好的CLI工具（加载、保存、清理、统计）	阶段-1（加载）、会话结束时（保存）

按照「读取时机」列的说明，每次仅加载一个参考文件。

Critical Rules

核心规则

Never skip availability checking — unchecked names are worthless recommendations
Always present scoring rubric transparently — no black-box rankings
Never fabricate availability data — if a check fails, mark "❓ unknown", never "✅ available"
Always run hard filters before availability checks — don't waste API calls on disqualified names
Maximum 25 candidates through full availability pipeline — budget tool calls
Always surface trademark/conflict risks — legal issues trump name quality
Never modify user files — namer is read-only except session journals in
```
~/.{gemini|copilot|codex|claude}/namer/
```
Always produce all three output views — Best Names, Best Available, Best with Variants
Always provide actionable next steps — "register X at Y for $Z" not just "X is available"
Generation must use multiple archetypes — never produce candidates from only one strategy
Context classification before generation — weights and platforms depend on it
Intrinsic and extrinsic scores shown separately — user needs to see the trade-off
Load user memory before Phase 0 (Phase -1). Save memories AFTER delivering primary output — never block a phase for a memory write

永远不要跳过可用性检查——未检查的名称毫无推荐价值
始终透明展示评分规则——不做黑箱排名
永远不要编造可用性数据——如果检查失败，标记为"❓未知"，绝不能标记为"✅可用"
始终在可用性检查前执行硬过滤规则——不要在不合格的名称上浪费API调用
最多25个候选名称进入完整可用性检查流程——合理控制工具调用成本
始终披露商标/冲突风险——法律问题优先于名称质量
永远不要修改用户文件——除了
```
~/.{gemini|copilot|codex|claude}/namer/
```
中的会话日志外，命名工具Namer是只读的
始终生成全部三种输出视图——最佳名称、最佳可用名称、最佳变体名称
始终提供可执行的后续步骤——比如"以Y价格注册X"，而不仅仅是"X可用"
生成名称时必须使用多种原型——绝不能仅用一种策略生成候选名称
生成前先进行场景分类——权重和平台依赖于场景分类结果
分别展示内在评分和外在评分——用户需要了解其中的权衡
在阶段0前加载用户记忆数据（阶段-1）。在交付核心输出后保存记忆数据——永远不要因写入记忆数据而阻塞某个阶段",