mcpField
G
gitmoji-conventional

gitmoji-conventional

github.com/morzecrew开发165 次安装11 周前更新
代码仓库

关于 gitmoji-conventional

用于编写和检查 Gitmoji + Conventional Commits 提交信息的技能。它指导类型选择、正文编写和格式规范，并通过脚本检查提交信息；PR 标题不在检查范围内。

主要功能

  1. 01依据主要变更选择提交类型
  2. 02采用 Gitmoji 和 Conventional Commit 格式
  3. 03编写简洁且有用的提交正文
  4. 04检查信息、文件和提交范围
  5. 05遵循破坏性变更与回退规范

适用场景

  1. 01为代码变更起草提交信息
  2. 02审查分支中的提交信息
  3. 03按文档规则拟定 PR 标题

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/morzecrew/agent-skills --skill gitmoji-conventional

安装后在 Claude Code 中输入/gitmoji-conventional确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
commit-format.md
gitmoji-mapping.md
scripts/
check_commit_msg.py

详细介绍

Gitmoji + Conventional Commits

<gitmoji> <type>[optional scope][!]: <description>

✨ feat(api): add OAuth login support
🐛 fix(auth): handle expired refresh tokens
♻️ refactor(cache): extract eviction policy

格式、破坏性变更标记、revert 格式、页脚、SemVer 映射和 PR 标题规则见 references/commit-format.md。check_commit_msg.py 会检查提交消息相关内容；它不会检查 PR 标题——它会读取消息文件、字面消息和提交范围，而标题不会经过它。撰写这两者时都要加载参考文档。以下是任何检查都无法替你决定的部分。

选择主要类型

  1. 确定主要变更。
  2. 从 references/gitmoji-mapping.md 中选取对应的 gitmoji——选择时要加载该文档。
  3. 使用该 gitmoji 映射的类型。绝不要自行创造 gitmoji 或类型。

常见搭配：✨ feat、🐛 fix、♻️ refactor、⚡️ perf、📝 docs、✅ test、👷 ci、📦️ build、🔧 chore、⏪️ revert。破坏性变更不是一种类型：💥 与底层类型搭配使用 !，因此版本发布分组仍会读取其下方的 feat/fix。

一次提交，一个语义主题。 如果变更涉及多种类型，就选一个最适合用作发布说明标题的类型；其余内容放在正文中说明。按用户影响力打破平局：

fix > feat > perf > refactor > build > docs > test > chore

附带的编辑不计入——功能提交即使也修改了测试，仍然是 ✨ feat，因为这些测试是为该功能而存在的。两个真正独立的变更应拆成两次提交；应明确说明这一点，而不是把它们混在同一个主题中。

发布工具会读取类型，因此标错类型是有代价的：标为 chore 的功能不会进入发布说明，而标为 feat 的重构会导致版本号虚高。根据变更的实际作用选择，而不是根据写代码时的感受选择。

正文要为 git blame 而写，而不是为审查者而写

目标是不超过 12 个非空行；超过 20 行则视为严重失败。 页脚和围栏代码块不计入，因此必须随提交保留的证据——堆栈跟踪、失败的配置、基准测试表格——应放在围栏代码块中。

正文应包含：差异本身无法体现的动机（约束、Bug 的成因、被否决的替代方案），读者无法预料的后果，以及在省略看起来像疏忽的内容时，明确说明变更有意不做什么。

正文不应包含：

  • 过程叙述——“然后我运行了测试，发现了 X”。判断标准是：正文描述的是作者做了什么，而不是代码的新状态。这类内容应放在 PR 描述中。
  • 证据堆砌——测试数量、覆盖率、变异测试统计。它们在 PR 中是最新信息，在 git log 中则会过时。例外：某个数字本身就是原因（“p99 为 240ms，超过了 150ms 的阈值”）。
  • 用更长的说法重述主题，或罗列差异中已列出的文件。
  • 流程评论——遵循了哪项技能、在哪一轮发现问题、进行了多少轮。

如果解释需要更多篇幅，那就不适合放在提交正文中：将其写入 RFC、议题或 PR 描述，并用一行链接过去。如果正文需要添加标题，或每段都涉及不同主题，那就说明变更打包过多——六段通常意味着六次提交，这正是上文主要类型规则所述的情况，而不是在汇报真正的发现。

检查

python3 skills/gitmoji-conventional/scripts/check_commit_msg.py --message "✨ feat(api): add OAuth login"
python3 skills/gitmoji-conventional/scripts/check_commit_msg.py --range main..HEAD   # audit a branch
python3 skills/gitmoji-conventional/scripts/check_commit_msg.py --file "$1"          # commit-msg hook

正文长度上限放在脚本中，而不是写在这里的说明中，是有原因的：因为有人读过这条说明、表示认同，却在同一会话中无视了它，所以才添加了这一限制（drift-to-gate）。

只输出提交消息或 PR 标题——不要解释，也不要给出其他选项，除非用户要求。

相关技能

  • keep-a-changelog — 将相同的变更整理成面向用户的 CHANGELOG.md 条目；这里的破坏性提交需要在那边明确添加破坏性变更条目。如果没有这项技能，也仍然要撰写该条目：破坏性变更没有对应的变更日志条目才是问题，而不是缺少这项技能。

评论

支持 Markdown