命名策略师
以隐喻驱动的结构化流程，为产品、SaaS 和品牌取出令人难忘的名字，并主动过滤 AI 式俗套命名。
SKILL.md 的 allowed-tools 收敛为只读类命令（Read/Grep/Glob、whois、npm view、gh repo view、WebSearch/WebFetch），无写入、无删除、无凭据接触；数据流透明：候选名称会通过 whois/curl/搜索发送到外部服务，文中明确说明。扣分点：外部网络查询（域名/平台查询会暴露用户的命名意向）未要求用户确认，无敏感数据处理的明确说明，也无回滚/失败恢复指引；发布者未经验证，但按规则不因此额外扣分。扣除约 8 分。
流程结构自洽：7 步流程、循环回退条件明确、可用性检查为强制门（Step 5）并有降级方案（whois 缺失时用 curl）。扣分点：捆绑的 check-availability.sh 脚本源码未在证据中呈现，无法静态确认其行为；无测试、无边界/异常输入处理说明；whois/curl 对网络环境敏感且可能产生误判（availability.md 自身也承认误报风险）。静态读上限 10，扣除至 9。
触发语义清晰：description 明确列出适用对象（产品/SaaS/品牌/开源/bot），Step 1 命名简报定义输入，Step 7 定义输出格式，有明确的不适用边界（'不是命名的事就别做'隐含于流程）。扣分点：主要面向英文命名；语言文件仅有波兰语、葡萄牙语，无中文文件，无中文支持说明；核心可用性检查依赖 whois 及海外平台（npm、PyPI、GitHub、t.me、WordPress API），在中国大陆网络下可达性存疑。扣除约 6 分。
文档分层良好：SKILL.md 仅作入口，上下文预算管理明确，参考文件按需加载并有清晰的加载表；README 提供安装说明；MIT 许可、分支保护、markdownlint 与链接检查 CI、详细的 CONTRIBUTING 与维护者响应预期（单人维护、1-2 周）。扣分点：无版本号、无 CHANGELOG、无已知限制章节；发布者身份未经验证但仓库治理证据本身较充分。扣除约 3 分。
核心任务（产出经过可用性验证、有来源故事的候选名）流程设计完整且合理，抗 AI 槛尾过滤、强制可用性检查提供真实增量价值。扣分点：静态审查无法验证实际输出质量；最终结果仍需用户自行复核商标与法务；自动检查自身承认可能误报，需人工验证。静态上限 7，给 6。
有部分可审计的一手材料：案例研究要求可验证来源、CI 有 lint 与链接检查工作流、贡献指南要求事实可溯源。扣分点：无测试套件、无真实执行证据；案例中的召回率数据（68.8% vs 38.1%）未给出可查来源；多数参考文件内容未包含在证据中。静态上限 5，给 4。
- 可用性检查依赖 whois 及多个海外服务（npm、PyPI、GitHub、t.me 等），在中国大陆网络下可能不可达或超时，导致流程在 Step 5 受阻或产生误判。
- check-availability.sh 的源码未包含在本次审查证据中，其行为、退出码与误报模式无法静态验证，使用前请人工阅读。
- 可用性查询会将候选名称发送至外部服务，可能暴露用户尚未公开的产品命名意向；对保密项目建议跳过或手动执行检查。
- 技能以英文为中心，无中文命名语言文件，中文品牌场景下的适用性有限。
- 无版本号与更新日志，升级时无法确定内容变更。
这个 Skill 能做什么，适合哪些场景？
这是一个 Claude Code 技能，指导 AI 扮演命名策略师，通过七步流程为产品、SaaS、品牌、开源项目和 App 命名。它先建立命名简报，再探索隐喻概念领域，而非查同义词表。流程中间的候选生成、过滤、可用性检查和评分全部自主完成，用户只看到经过可用性验证的 3-5 个终选名单。技能包含 14 个参考文件和一个可批量检查域名、npm、PyPI、GitHub、Telegram 等平台的脚本。
通过向用户提问建立命名简报（功能、受众、气质、目标平台等六个问题）；加载 metaphor-mapping.md 等 14 个按需加载的参考文件来探索隐喻领域、生成 30-50 个候选名；用反模式清单过滤掉 -ly/-ify 等 AI 俗套；运行捆绑的 scripts/check-availability.sh 以及 whois、curl、npm view、WebSearch 等命令实际验证域名、npm、PyPI、GitHub、crates.io、RubyGems、WP 插件和 Telegram 的可用性；最后按加权评分框架给出带起源故事、可用性状态和标语建议的终选名单。
- 独立开发者在发布 SaaS 产品前，需要既有好故事又能注册到域名的产品名。
- 开源项目作者需要 CLI 友好、不与 npm/PyPI 现有包冲突的库名。
- 品牌团队在现有品牌家族内为新产品线命名，需要遵循 brand-architecture 指南。
- 面向非英语市场（如波兰语、葡萄牙语）的产品，需要跨语言发音和含义检查。
- 创业者想过滤掉 AI 生成的 -ly/-ify 式俗套名，获得有压缩故事的候选名并附带标语建议。
这个 Skill 有哪些优点和局限？
- 方法论具体：7 步流程、加权评分、反模式清单，而非泛泛建议。
- 强制实际可用性检查，通过 whois/curl/npm 等真实工具验证，不凭记忆猜测。
- 上下文管理设计合理：15+ 参考文件按需加载，简单任务只加载 2-3 个文件。
- 流程有回环机制：候选不足或评分过低时回到更早步骤，而不是降低标准。
- MIT 许可、开源，欢迎贡献语言和行业指南。
- 为 Claude Code 设计，/naming 斜杠命令和 allowed-tools 前沿格式需适配才能用于其他平台。
- 可用性检查依赖本地命令（whois、curl、gh、npm）和网络，缺工具时检查质量下降，whois 失败会退化为只检查网站是否在线。
- 仓库未展示测试套件或实际命名案例输出，效果无独立验证。
- 核心主张（真实词名约 68.8% 回忆率 vs 生造名 38.1%）来源未在源材料中说明。
如何安装这个 Skill？
克隆仓库到 Claude Code 的技能目录：项目级安装 mkdir -p .claude/skills && git clone https://github.com/glacierphonk/naming.git .claude/skills/naming；个人级（所有项目可用）mkdir -p ~/.claude/skills && git clone https://github.com/glacierphonk/naming.git ~/.claude/skills/naming。前提是已安装 Claude Code。
如何使用这个 Skill？
在 Claude Code 中输入 /naming，然后用一句话描述你要命名的东西；也可以自然语言描述命名需求，Claude 会自动加载相关参考文件。可用性检查环节需要本地具备 whois、curl 等命令且可联网；脚本未覆盖的平台（应用商店、社交账号）通过 WebSearch 检查。快速会话只会加载 2-3 个参考文件。