mcpField
C
commit-messages

commit-messages

github.com/athola开发34397 次安装1 天前更新
代码仓库

关于 commit-messages

commit-messages 是根据已暂存变更起草 Conventional Commit 消息的工作流技能。它指导变更分类、主题和正文撰写，并在将草稿写入 commit_msg.txt 前检查格式与用词。

主要功能

  1. 01检查已暂存变更和近期提交
  2. 02按提交类型与范围分类变更
  3. 03起草主题、正文和页脚
  4. 04适用时添加讨论解决标记
  5. 05检查措辞与格式规则

适用场景

  1. 01为已暂存工作准备 Conventional Commit 消息
  2. 02记录问题引用或已解决的讨论
  3. 03检查提交消息长度与风格

安装

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

$npx skills add https://github.com/athola/claude-night-market --skill commit-messages

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

详细介绍

Conventional Commit 工作流

适用场景

  • 根据已暂存的更改生成 Conventional Commit 提交消息

不适用场景

  • 准备完整的 PR：使用 sanctum:pr-prep
  • 修改现有提交：直接使用 git

步骤

  1. 收集上下文（并行运行）：

    • git status -sb
    • git diff --cached --stat
    • git diff --cached
    • git log --oneline -5
    • sem 可用时（参见 leyline:sem-integration）： 使用 sem diff --staged --json 查看实体级更改

    如果没有已暂存的更改，请告知用户并停止。

    sem 输出可用时，在提交主题和正文中使用实体名称 （函数、类、方法），而不要解析原始 diff 片段。例如， 写“add function validate_webhook_url”，而不是 “add validation logic to notify.py”。

  2. 分类：选择类型（feat、fix、docs、refactor、 test、chore、style、perf、ci），以及可选的作用域。

  3. 起草消息：

    • 主题：<type>(<scope>): <imperative summary>（最多 50 个字符）
    • 正文：说明做了什么以及原因，每行不超过 72 个字符
    • 页脚：BREAKING CHANGE、问题引用，以及下方的讨论标记

3a. 讨论标记：如果更改解决了 Discussions 看板中的一项发现， 请另起一行添加标记：

Addresses-Discussion: #654
Addresses-Discussion: #604, #610

这是 scripts/reconcile_discussions.py 接受的唯一证明，表示一项发现已解决。它会发布解决评论 并关闭讨论，因此看板不会继续显示已经完成的工作。

仅当此提交解决了该发现时才添加。 仅仅提及讨论的正文 会被视为引用，绝不会写回。这个区别至关重要： 6b28aa1a 写道“posted 13 insights to discussions #424-#436”，这是开启这些讨论的提交。在这里添加标记， 就等于对尚无人处理的发现宣布“已解决”。

需要时，可以在正文中引用讨论以补充上下文。 但标记仅用于表示解决。

  1. 赘词检查：拒绝使用以下词语，并替换为朴素的表达：

    避免使用替换为
    leverage、utilizeuse
    seamlesssmooth
    comprehensivecomplete
    robustsolid
    facilitateenable
    streamlinesimplify
    optimizeimprove
    delveexplore
    multifacetedvaried
    pivotalkey
    intricatedetailed

    也要避免：“it's worth noting”、“at its core”、 “in essence”、“a testament to”。

4a. 字符级赘词检查：加载 shared/output-hygiene.md （Contract A）并去掉以下标记。如果该模块不可用，则以内联规则替代：

标记替换为
作为连接词的 "+"and（版本号和代码中的 + 保留）
em-dash —冒号、句号、逗号，或改写
作为正文标点的 --冒号或改写
作为连接符的箭头 -> / →to / into
弯引号 “ ” ‘ ’直引号 " 和 '
事实罗列后以 , so 收尾删除读者可自行推断的结果，否则另起一句

4b. 主题检查（Contract B）：从读者能感知的效果描述更改。 不要提及 AI 来源，也不要提及具体移除的标记。不要写 remove AI slop、de-slop、 AI-generated content、AI phrasing、replace em-dashes 或 remove smart quotes。检查方式：如果主题只有在表达“我 清理了 AI 输出”时才说得通，就重写。例如，写 docs: clarify the setup section，而不是 style: replace em-dashes with colons。

  1. 写入 ./commit_msg.txt 并预览。

规则

  • 绝不使用 git commit --no-verify 或 -n
  • 为人而写，而不是为了显得出众
  • 如果 pre-commit 钩子失败，修复问题
  • 此技能负责起草消息，不会提交。提交者在报告提交已落地前，须确认 HEAD 已前进（先后运行 git rev-parse HEAD）。自动修复钩子会中止提交，同时打印一段看起来像成功的末尾输出，因此钩子输出不能作为证据。参见讨论 #614。

退出标准

  • 已在工作目录中写入 commit_msg.txt，其中包含起草的 conventional commit 消息
  • 主题行遵循 <type>(<scope>): <summary> 格式，且不超过 50 个字符
  • 冗词检查通过：消息中不含任何禁用词（leverage、utilize、seamless、comprehensive、robust 等）
  • 字符级检查通过：不得使用 em dash、不得用 + 连接句子成分、不得使用智能引号、不得用 -> 连接句子成分
  • 正文中表示结果的 , so 尾句最多出现一次（scripts/slop_score.py --audit 会将每处列为 so_connective）
  • 如果没有暂存任何内容，技能会立即停止，并报告“没有暂存内容”，且不会生成提交消息

评论

支持 Markdown