namekit

namekit

根据命名惯例为项目取名，而不是面对一张白纸；只返回确实可用的名称。两种明确的模式：

• generate。 将项目描述转化为符合用户命名惯例的候选名称排名列表，然后针对用户挑选的两三个名称，查询域名、npm 和 GitHub 命名空间，并选出一个。
• check。 查询用户已有的名称，并报告每个名称是否可用。不生成名称。

之所以需要一个技能，而不是一句话就能完成：如果不加约束，模型会返回同一个创意的十种拼写，编造没人使用的惯例，还从不检查候选名称是否已被占用。namekit 按顺序解决了这三个问题。

何时触发

• generate。 “给这个项目取名”、“我该怎么称呼它”、“给我一些名字创意”、“为 X 想个名字”、“我需要给我的新 SaaS 取个名字”。
• check。 “growaloy 被占用了吗”、“检查这个名字是否可用”、“有人注册了这个 npm 包吗”。

用户提供描述时，使用 generate。用户提供名称时，使用 check。用户两者都提供时，先对他们给出的名称运行 check，再提供 generate，因为用户已经喜欢的名称比你想出的任何名称都优先。

查询（两种模式通用）

三个命名空间，三条命令。每一项都是公开的 HTTP 契约，因此可以安全固定。

# domain registration: 404 = not registered, 200 = registered
curl -s -o /dev/null -w '%{http_code}' -L --max-time 10 https://rdap.org/domain/<name>.com

# npm package: 404 = free
curl -s -o /dev/null -w '%{http_code}' --max-time 10 https://registry.npmjs.org/<name>

# GitHub org or user handle: exit 0 = taken; "HTTP 404" on stderr = free
gh api /users/<name> --silent

只将列出的响应视为判定结果。 域名或 npm 的状态码不是 200 或 404 时（包括 429、5xx，以及超时后的 000），结果均为未知。对于 gh api，只有退出码为 0 才表示已被占用；只有退出码非零且 stderr 显示 HTTP 404 才表示可用。其他任何失败都表示未知：gh help exit-codes 列出了 1（任何失败）、2（取消）和 4（缺少身份验证），这些都不能证明该账号名可用。未知的查询重试一次。重试后结果仍未知的名称，既不能移除，也不能判定为可用；应将该命名空间报告为未知，并说明原因。

查询 .com，再加上能体现项目定位的第二个 TLD（开发者工具用 .dev，模型产品用 .ai，面向本地受众则用相应国家的 TLD）。跳过项目永远不会使用的命名空间：仅有 CLI 的工具不需要 npm 名称，内部工具也不需要域名。

每次查询两个或三个名称。 RDAP 一次只处理少量查询，突发请求会返回 429，而 429 不是判定结果。批量查询几十个名称会丢弃查询域名时获得的结果。

将每项结果表述为相应查询本身能证明的结论。 RDAP 返回 404 表示该域名尚未注册，并不表示该域名正在出售、价格实惠或没有商标问题。请说“尚未注册”，让用户自行了解价格。

遇到问题时降级处理，而不是阻塞。 如果没有 shell、网络或 gh，说明跳过了哪些查询，并仅根据四项评估标准返回排名后的候选名称列表。说明限制的候选列表胜过完全不给列表。

---

模式：generate

1. 复述，然后访谈

先用一句话复述项目描述，再提问。这里误读一句，后面就要多花一轮来纠正。

然后进行访谈。候选名称池由六项构成；只问描述中尚未明确的内容，并逐项对照描述核查，不要因为描述看起来完整就跳过这一轮（“面向中小企业的 AI 增长平台”仍然没有说明受众、语气或使用场景）。每轮最多问五个问题，并一次性提问：

1. 它的用途。 所属领域和预期结果。
2. 面向谁，以及他们阅读什么语言。 面向孟加拉语读者的受众，会让你考虑英语受众不会考虑的词根。
3. 语气。 朴实、技术化，还是活泼。
4. 要包含或避免的词。 创始人通常各有一个。
5. 名称会在哪里输入。 域名、软件包名称、CLI 命令、组织账号名。这决定长度容忍度，也决定运行哪些探查。
6. 它会有多持久。 临时内部工具与需要坚守十年的产品，值得投入的精力不同。

完成标准： 候选名称池中每项尚未回答的内容都已有答案，或明确表示“无所谓”；复述也没有被纠正。

2. 确定命名惯例

按以下顺序逐项判断，在第一个能得出答案的步骤停下：

1. 用户明确说明。 用户直接说出惯例（“所有名称都加上 aloy 后缀”）。
2. 从示例推导。 用户举出自己的名称（“像 codealoy、growaloy、saasaloy 这样”），共同的尾部就是惯例。
3. 按要求查看其代码仓库。 仅当用户指定时才执行：gh repo list <owner> --limit 100 --json name。查看项目，而非 Fork，因为 Fork 的名称沿用的是别人的惯例。
4. 询问。 提供后缀、前缀、混成词或不加修饰这几种选择。

每次都要重新确认命名惯例。 切勿保存惯例，也不要退回到诸如 kit 这样的默认惯例；用户改变想法后，保存的惯例就会过时，而已发布的名称仍然有效。

在输出中说明最终确定的惯例，这样如果理解有误，只需纠正一句，而不用推翻整个候选名单。

完成标准： 惯例已写明为修饰成分及其位置，或用户已选择不使用修饰成分。

3. 挖掘词根并构建候选名称

从四种不同来源提取词根，让候选集合真正多元，而不是同一个想法的十种变体：

• 领域名词。 事物涉及什么：code、saas、ledger。
• 结果动词。 它为谁做什么：grow、ship、learn。
• 用户或其素材。 谁使用它：dev、shop、desk。
• 隐喻，或非英语词根（当访谈中提到非英语受众时）。

非英语词根必须通过一道门槛：在日常用法中，必须有一种拉丁字母转写占主导。如果一个词根有两种拼法，而且人们确实都会使用，就直接舍弃，而不是给它较低的评分；因为如果受众会用三种方式输入一个名称，那它就无法胜任名称唯一的工作。

根据衔接规则将每个词根与修饰成分组合，依据评分标准评分，然后筛选。生成至少 25 个原始候选名称，并将最佳的 12 个排入候选名单。这个数量是有意安排的：用户每轮会探查两到三个名称，因此在需要重新生成前，名单必须能支撑好几轮探查。

完成标准： 排名靠前的 12 个名称所用词根至少来自四种来源中的三种，并且每个名称都附有一句理由和评分结论。

4. 先展示候选名单，再探查用户挑选的名称

先列出排名前 12 的名称，再进行任何探查。 名称优先展示，使用一张表格列出名称、词根和来源、边界案例及评分标准结论，暂不添加可用性列。用户会先看完整份名单，对创意发表看法，让他们始终参与创意工作的核心环节。

然后请用户挑选两到三个名称进行探查。如果可以使用 AskUserQuestion，就用它；否则用一行文字询问。只探查用户挑选的名称。 未挑选的名称不进行探查，无论其评分标准分数多高。

对用户挑选的名称运行探查。任何一项命中都会淘汰该名称。 可用性在这里是结论，而不是分数，因为用户无法拥有的名称不算候选名称。

唯一的例外：用户已经拥有的命名空间可以通过检查，并视为属于用户。 如果存在代码仓库，则从 Git 远程仓库解析其所有者（gh repo view --json owner）；否则从提供该命名惯例的仓库中解析；两者都无法确定时，询问一次。没有这个例外，内部命名惯例就会否决自己的作品集，这就是 codealoy 无法通过 codealoy 筛选的原因。

如果一批名称的探查结果全都不通过，则逐一报告用户挑选的名称及淘汰它们的探查结果，重新列出尚未探查的候选名称，并请用户挑选下一批两到三个。重复此流程，直到有一个名称可用或用户停止。绝不要自动选择下一批，因为挑选权属于用户。

只有候选名单用尽时才重新生成。 当 12 个名称全部经过探查且都已被占用时，再次运行挖掘词根并生成候选名称，排除已被占用的词根，并以相同方式展示新名单。最多进行两轮生成。

完成条件： 每个经过探查的命名空间中至少有一个经过探查的名称可用，或用户停止流程；并且每个经过探查的名称都针对实际运行的每项探查带有可用、已占用或未知的结果。

5. 选出最终名称，然后只搜索一次

将评分标准排名最高的可用名称选为最终名称。然后只进行一次网络搜索，且仅搜索该名称，以查找注册机构可能漏掉的现有产品或有效商标。如果搜索结果未能明确说明该对象是什么，则打开排名最高的结果。

如果命中，则改选下一个可用名称，并用一行说明冲突；新的最终名称也必须单独经过搜索，之后才能报告。重复此流程，直到某个最终名称通过搜索。如果没有剩下可用的备选名称，就说明这一点，并让用户回到挑选流程。只搜索最终选定的名称：注册机构的精确匹配检查成本低，而网络搜索结果模糊且成本高，因此只有在结果会改变决定时才值得搜索。

完成条件： 最终选定的名称已完成搜索且通过检查，或者已没有可用名称可选。

6. 交接

本技能中的每条交接指令都使用操作性语体：每句一条指令，使用主动语态和现在时，不用比喻。

在以下三个部分之前，以排名表的形式打印探测过的名称：

名称	根词（来源）	接缝	评分	.com	npm	GitHub
growaloy	grow（结果动词）	硬连接	4/4	可用	可用	可用

变更内容。 报告最终确定的约定、胜出名称及其一句话理由、用户探测了多少批次，以及是否运行了第二轮生成。列出注册表接受的每个探测名称，并注明淘汰它的探测结果。列出尚未探测的候选名称，以便用户之后可以再考虑。

最终位置。 namekit 默认不写入文件。仅当用户提出要求时，才写入 docs/names/NNNN-names-<slug>-YYYY-MM-DD.md，其中 <slug> 是项目的简短 kebab-case 名称，日期是文件的创建日期。要获取序号 NNNN，请在此工作树、git worktree list 列出的所有其他工作树，以及 origin/HEAD（运行 git fetch origin 后执行 git ls-tree --name-only origin/HEAD docs/names/）中，找出 docs/names/ 里的最高四位前导序号，并加一；如果没有，则从 0001 开始。请扫描这三个来源，否则并行工作树可能会取得相同序号。序号按目录分别计算，且绝不重用。若后续编辑，保持整个名称不变。若主机仓库说明了自己的产物约定，请遵循该约定。若无法访问文件系统，请将文档放在代码块中打印，并给出文件名。

下一步。 选定一个行动。名称已经选好，但尚未归任何人所有，因此应按访谈中关于类型化表面的回答所暗示的顺序，认领项目实际需要的命名空间。安装后，使用 repokit 为新仓库设置 About 面板和主题；否则使用 gh repo create。如果该名称来自创意讨论，请将 ideakit 作为备选名称，记录回该创意讨论的日志。namekit 绝不注册域名、发布软件包或创建组织。

接缝规则

名称不佳往往源于连接处；三种情况涵盖所有约定，因为规则关注的是连接处相邻的字母，而不是某个特定词缀。

• 硬连接。 根词的末尾与词缀的开头不会冲突，因此直接拼接。code + aloy → codealoy。前缀形式：open + forge → openforge。
• 省略。 两者重叠，因此删除重复部分。data + aloy → dataloy，而不是 dataaloy。前缀形式：auto + optimize → autoptimize。
• 拒绝。 接缝造成元音堆叠或难以念出的音节，且无法通过省略来解决。idea + aloy 省略后得到 idealoy，读起来像 “ideal-oy”。舍弃根词，另选一个。

评分标准

四项标准，分为通过、较弱或不通过。按通过项数量排序；若并列，则按语义契合度打破平局。

• 语义契合度。 根词说明了该事物的用途。
• 读音。 三到四个音节，且第一眼就能正确读出。
• 接缝质量。 按照接缝规则，采用干净的硬连接或省略。
• 听音拼写。 听到名称的人只会有一种拼写方式。

评分标准刻意不包含可用性。可用性是先展示候选名单，再探测用户选中的名称中的结论，而不是第五项标准，因为评分标准用于排列用户尚未探测的名称。

---

模式：check

对用户提供的名称运行探测。不生成、不排序、不筛选，因为没有候选名单需要精简。

应用相同的所有者例外：如果某个命名空间解析到用户自己的所有者名下，则标记为属于你，而不是已被占用。这种情况在此模式下很常见，因为人们通常会检查自己已经部分拥有的名称。

交接

变更内容。 每个名称占一行，注明它在各个命名空间中的结果（可用、已被占用、未知或属于你）。说明每个未知结果的原因。列出跳过的探测项。

落地情况。 没有写入任何内容，也没有注册任何内容。请明确说明这一点。

下一步。 根据结果选定一个行动。如果有名称可用，就去认领它：如果已安装 repokit，就为新仓库的元数据指定 repokit；否则运行 gh repo create。如果所有名称都已被占用，就运行 generate，围绕相同的想法挖掘新的名称词根。

---

备注

• namekit 只负责命名，不做其他事。 不设计徽标、标语、定位或品牌形象，也不重命名现有代码库中的标识符。
• 不检查社交媒体账号。 对社交平台进行无头检查会受到速率限制，并产生假阴性；错误地判断为“已被占用”比不给出结果更糟。
• 优先采用探测项的状态码，而不是抓取页面，因为状态码是稳定的契约，而页面不是。