GitHub仓库命名应采用小写短横线格式，以核心功能开头，避免冗余词与版本号，保持简洁唯一，并优先遵循组织内部约定。
如果您正在创建一个新的 GitHub 仓库，但不确定如何为其命名，则可能是由于缺乏统一的命名参考标准。以下是符合开源协作惯例与平台识别逻辑的命名实践：
一、使用小写字母与短横线分隔
GitHub 仓库名在 URL 中直接体现，系统对大小写不敏感，且空格和特殊字符（如下划线、中文、点号）易引发路径解析异常或工具链兼容问题。采用全小写加短横线（kebab-case）格式可确保最大兼容性与可读性。
1、避免使用大写字母，例如不要命名为 MyProject 或 DataAPI。
2、用短横线代替空格或下划线，例如将 user management 改为 user-management。
3、不使用中文、emoji、标点符号（如！、@、#、.、_）或 Unicode 符号。
二、以项目核心功能或领域关键词开头
仓库名称应第一时间传达其主要用途或技术范畴，便于团队成员快速识别归属，也利于 GitHub 搜索与语义化归类。前置关键词有助于在组织级仓库列表中形成逻辑聚类。
1、若为前端组件库，优先使用 component-、ui-、web- 等前缀，例如 ui-button 或 web-form-validator。
2、若为 CLI 工具，使用 cli-、tool- 或对应动词前缀，例如 deploy-cli 或 migrate-tool。
3、若为特定语言绑定，加入 lang- 前缀或后缀，例如 rust-bindings 或 python-sdk。
三、避免冗余修饰词与版本号
仓库名不是发布说明，不应包含主观评价（如 best、final、new）、环境标识（如 dev、prod）或具体版本信息（如 v1、v2.3）。这些内容应交由 Git 标签（tag）和 README 明确表达，而非固化于仓库名中。
1、删除所有形容词类词汇，例如不要命名为 awesome-api-wrapper 或 super-fast-parser。
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
2、不嵌入开发阶段标识，例如避免 staging-backend 或 test-database-driver。
3、不包含 Git 分支名或版本字符串，例如禁止命名为 myapp-v2.1.0 或 myapp-main。
四、保持长度简洁且具备唯一性
过长的仓库名降低可输入性与记忆成本，同时增加命令行操作出错概率；过短则易与其他项目重名，尤其在公开组织下可能引发混淆。理想长度为 2–4 个单词组合，总字符数控制在 30 字符以内。
1、优先压缩介词与冠词，例如将 the-data-processing-service 改为 data-processor。
2、在组织内检查现有仓库列表，确保新名称不与已有仓库完全重复。
3、若需区分同类型多个实现，使用功能性后缀而非序号，例如 parser-json 与 parser-xml，而非 parser-1、parser-2。
五、遵循组织内部约定优先
当仓库属于公司、开源组织或团队时，命名需服从已发布的内部规范。此类约定可能包括强制前缀（如 acme-）、分类目录编码（如 infra-、sdk-、demo-）或命名模板（如 {product}-{layer}-{function}）。
1、查阅组织的 CONTRIBUTING.md 或 README 中的“Repository Naming”章节。
2、确认是否要求强制添加团队缩写，例如 ios-team-networking 或 ml-group-eval-utils。
3、若存在自动化 CI/CD 流水线依赖仓库名结构，必须匹配其正则匹配规则，例如要求以 *-service 结尾。
