Naming Buddy

naming-buddy — 命名困难症救星

给一段逻辑/用途描述 + 目标语言,得到 3-5 个候选名、推荐理由、以及原名/坏味道诊断。 告别 data、temp、flag、info、manager——让名字直接说清意图。

何时触发

用户说:

• /naming-buddy
• 帮我起个名字
• 这个变量叫什么好
• 给这个函数命名
• 命名建议
• 这个名字好不好
• xxx 这个名字有没有问题
• 帮我看看这几个命名
• 类名怎么起、文件名叫什么、常量名叫什么

工作流

第 1 步:搞清三件事

在给出任何候选名之前,必须先明确:

1. 命名类型:变量 / 函数 / 类 / 接口 / 文件 / 包 / 常量 / 布尔 / 枚举 / 参数
2. 目标语言:决定 case 惯例(camelCase / snakecase / PascalCase / kebab-case / UPPERSNAKE_CASE)
3. 职责描述:它做什么、存什么、代表什么——这是命名的根本依据

若用户没有提供语言或职责描述,先追问,不要凭空猜测。追问示例:

• "请问是哪种语言?Go / Python / TypeScript / Java / Swift / Rust / Dart…?"
• "能描述一下这个函数/变量的具体职责吗?它做什么事情?"
• "它是个布尔值还是函数?读来还是写去?"

第 2 步:给 3-5 个候选名

按推荐度从高到低排列,格式:

候选名(按推荐度排):
1.   — 
2.   — 
3.   — 
[4.   — (适用特定场景时)]
[5.   — (适用特定场景时)]

给候选名的原则:

• 第 1 名:最符合该语言惯例 + 意图最清晰的
• 第 2-3 名:语义相近但侧重点不同(更简洁 / 更明确 / 更符合项目词汇表)
• 第 4-5 名:适用于特定上下文(如有对应配对名、领域术语时)
• 每个名字都附一句中文理由,说明为什么而不只是"这样更清晰"

第 3 步:坏味道诊断

若用户给出了原名,或候选时需要对比,主动指出以下坏味道:

| 坏味道类型 | 典型例子 | 问题所在 | |-----------|---------|---------| | 过于泛化 | data、info、result、value、item、obj | 什么都能叫这个,看不出业务含义 | | 动作名词太泛 | manager、handler、processor、util、helper、service(滥用) | 掩盖真实职责 | | 临时占位 | temp、tmp、foo、bar、xxx、test2 | 临时名字进了正式代码 | | 布尔无前缀 | verified、active、loaded | 不加 is/has/can 容易误用为名词 | | 匈牙利命名 | strName、boolFlag、intCount | 类型信息放名字里,现代 IDE 已无必要 | | 过度缩写 | usrCntr、getMsgCnt、calcRcvdPkts | 三个月后连自己都看不懂 | | 拼音混入 | yongHu、zhanghao | 项目统一英文时不要用拼音 | | 序号命名 | user1、data2、list3 | 区分靠数字而不是语义 | | 类型即名字 | userList、nameString、countInt | 名字里带类型后缀,通常多余 | | 反义不对称 | getUser + removeUser 但本应对称 addUser + removeUser | 动词不一致破坏 API 可读性 |

第 4 步:附上语言惯例提示(如有必要)

若用户对 case 约定不熟悉,或给出的名字 case 不对,给一句提示:

惯例提示: 中  用 。
示例:Go 中导出函数用 PascalCase(如 GetUser),内部函数用 camelCase(如 getUser)。

输出模板

## 命名建议

**命名类型:**
**语言:**(惯例:)
**职责:**

**候选名(按推荐度排):**
1. ``  — 
2. ``  — 
3. ``  — 
[4. ``  — ]
[5. ``  — ]

**坏味道诊断:**
[若原名存在问题]
- 原名 `` 的问题:
[若无明显问题]
- 原名无明显坏味道。

**惯例提示:**

命名惯例速查表

| 语言 | 变量 | 函数/方法 | 类/类型 | 常量 | 文件名 | |------|------|----------|--------|------|--------| | Go | camelCase | camelCase(内) / PascalCase(导出) | PascalCase | 全大写 MAX_SIZE 或包级 camelCase | snakecase.go | | Python | snakecase | snakecase | PascalCase | UPPERSNAKECASE | snakecase.py | | TypeScript / JS | camelCase | camelCase | PascalCase | UPPERSNAKECASE | kebab-case.ts / PascalCase.tsx | | Java | camelCase | camelCase | PascalCase | UPPERSNAKECASE | PascalCase.java | | Kotlin | camelCase | camelCase | PascalCase | UPPERSNAKECASE | PascalCase.kt | | Rust | snakecase | snakecase | PascalCase | UPPERSNAKECASE | snakecase.rs | | Swift | camelCase | camelCase | PascalCase | lowerCamelCase | PascalCase.swift | | Dart / Flutter | camelCase | camelCase | PascalCase | lowerCamelCase | snakecase.dart | | C# | camelCase(私有) / PascalCase(公有) | PascalCase | PascalCase | PascalCase / UPPERSNAKECASE | PascalCase.cs | | Ruby | snakecase | snakecase | PascalCase | UPPERSNAKECASE | snakecase.rb | | CSS / HTML | kebab-case | — | — | — | kebab-case.css | | Shell / Bash | snakecase | snakecase | — | UPPERSNAKE_CASE | snake-case.sh |

布尔命名专项:

| 语言 | 推荐前缀 | 示例 | |------|---------|------| | Go | is / has / can / should | isActive、hasPermission | | Python | is_ / has_ / can_ | is_verified、has_children | | TypeScript/JS | is / has / can / should | isLoading、canSubmit | | Java/Kotlin | is / has / can | isEnabled、hasError | | Swift/Dart | is / has / can | isSelected、canEdit |

坏味道清单

过于泛化的词(见到要警惕):

data  info  result  value  item  obj  object  entity  record
temp  tmp   buf     flag   state status  content  payload
manager  handler  processor  util  utils  helper  service(滥用)

布尔命名常见错误:

• verified → 应为 isVerified
• active → 应为 isActive
• loaded → 应为 isLoaded
• error → 用于布尔时应为 hasError

函数/方法命名动词推荐:

| 动作 | 推荐动词 | 避免 | |------|---------|------| | 取数据 | get、fetch、load、find、query | retrieve(太正式)、obtain | | 检查/判断 | is、has、can、check、validate | verify(常与"核验"混) | | 创建 | create、build、make、new、init | generate(通常指生成内容,非对象) | | 转换 | to、from、convert、transform、map、parse | change | | 更新 | update、set、apply、patch、modify | edit(通常是 UI 层用词) | | 删除 | delete、remove、clear、purge | destroy(过于强烈,慎用) | | 发送 | send、publish、dispatch、emit、push | do(完全不说明意图) |

硬规则

1. 意图优先:名字表达"这东西是什么 / 做什么",不表达"它的类型是什么"。
2. 遵循语言惯例:camelCase / snake_case 等不能混用,Go 导出用 PascalCase 不能省。
3. 布尔必须有前缀:is/has/can/should 等;不加前缀的布尔容易被误当名词使用。
4. 不臆造领域术语:不确定业务含义时先问,不随便编造词汇。
5. 长度适中:

• 过短:缩写到看不懂(usrCntr、msgCnt)→ 展开
• 过长:超过 3-4 个单词的驼峰通常可以缩减(getUserByIdFromDatabase → findUser)

1. 项目词汇表一致:若项目里用 user 就不要用 account;用 create 就不要对称写 add。
2. 不做任何写操作:只给建议;不修改文件、不执行命令、不推送代码。

边界

• 纯 Claude 驱动,无需 bin 脚本或外部工具。
• 只做命名建议,不做代码重构;若需要批量重命名,提示用 IDE 重构功能。
• 不对框架专有命名(如 Django Model 字段、React Hook 前缀 use)做语言级规则覆盖——框架惯例优先。
• 若项目有既有命名规范文档(如 Google Style Guide、项目 CONTRIBUTING.md),告知 Claude 后以该规范为准。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: YuAICode
• Source: YuAICode/ai-skills
• License: MIT

Install and usage instructions live in the source repository linked above.