mcpField
G
git-commit-convention

git-commit-convention

github.com/edram开发052 次安装6 周前更新
代码仓库

关于 git-commit-convention

git-commit-convention 指导 Agent 按 Conventional Commits 1.0.0 规划并验证提交。内容涵盖提交边界、消息格式、版本影响和 AI 贡献署名。

主要功能

  1. 01根据变更集规划提交边界
  2. 02对照暂存变更验证提交消息
  3. 03说明格式、类型和版本影响
  4. 04涵盖破坏性变更及页脚语法
  5. 05按要求注明 AI 共同作者

适用场景

  1. 01将大型变更拆分为目的明确的提交
  2. 02依据暂存差异检查提交消息
  3. 03记录破坏性变更和问题引用
  4. 04在提交中注明 Agent 的贡献

安装

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

$npx skills add https://github.com/edram/skills --skill git-commit-convention

安装后在 Claude Code 中输入/git-commit-convention确认已加载。

包含的文件

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

references/
core-format.md
core-planning.md
core-types.md
features-ai-attribution.md
features-breaking.md
features-footers.md

详细介绍

Conventional Commits 1.0.0 定义了一种便于人类阅读、可供机器解析的提交消息格式。编写消息前，应根据完整的变更集规划提交边界；多轮对话可能产生多个连贯的提交，而不是一个包罗万象的提交。在规范中，feat 表示 MINOR，fix 表示 PATCH，破坏性变更表示 MAJOR；其他类型与版本的映射属于项目约定。

  • 只有 type 和 description 是必填项；其他内容均为可选项
  • scope 用于缩小受影响范围：feat(auth):、fix(api):
  • 破坏性变更使用 ! 后缀或 BREAKING CHANGE: 页脚（也可以两者都用）
  • 页脚标记遵循 Git trailer 约定
  • 默认使用英语，但应遵循项目现有约定——检查 git log，并沿用近期提交所使用的语言
  • 根据目的和依赖关系确定提交边界，而不是根据对话轮数
  • 根据暂存的差异验证每条消息：每项暂存变更都必须符合所述目的，且每项重要声明都必须有差异内容作为依据
  • 收到提交请求时，应在创建任何提交前说明拟定的提交计划；随后分别验证每个暂存提交
<type>[optional scope][!]: <description>

[optional body]

[optional footer(s)]

核心

主题说明参考
提交规划在提交前检查、分组、拆分并验证变更core-planning
格式完整语法、标头／正文／页脚规则及长度限制core-format
类型常见类型、项目级 SemVer 影响，以及各类型的适用场景core-types

功能

主题说明参考
破坏性变更! 语法和 BREAKING CHANGE 页脚——适用场景及用法features-breaking
页脚标记格式规则、问题引用及常见标记features-footers
AI 生成的变更只要 Agent 对提交有贡献，就必须添加 Co-Authored-By 署名features-ai-attribution

评论

支持 Markdown