mcpField
C
commit-message

commit-message

github.com/alannkl开发0103 次安装6 天前更新
代码仓库

关于 commit-message

此技能根据相关 Git 状态和差异起草提交信息，默认采用 Conventional Commits。它帮助开发者准确概括更改；暂存、提交和推送仍由外围工作流处理。

主要功能

  1. 01按请求范围筛选更改
  2. 02检查已暂存、未暂存和未跟踪更改
  3. 03起草 Conventional Commits 标题与正文
  4. 04指出迁移事项和必要后续操作
  5. 05依据差异核验提交信息

适用场景

  1. 01为已暂存更改撰写提交信息
  2. 02概括限定范围内的仓库更改
  3. 03起草注明必要操作的提交信息

安装

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

$npx skills add https://github.com/alannkl/skills --skill commit-message

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

详细介绍

提交消息

根据真实 Git 状态起草提交消息文本。默认使用 Conventional Commits。正文应简洁，说明行为、影响和所需后续操作。此技能仅负责起草消息；暂存、提交、修改提交和推送属于外围工作流。

工作流

  1. 确定范围。

    • 如果用户明确缩小了范围，请遵守该边界并忽略无关更改。
    • 如果存在已暂存的更改，除非用户要求总结所有更改，否则默认仅总结已暂存的更改。
    • 如果没有已暂存的更改，则使用相关的未暂存、更改未跟踪文件或用户提供的更改。
    • 总结未跟踪文件前，先检查其内容；git diff 不会显示这些文件的内容。
    • 如果没有相关更改，请如实说明，不要凭空编写消息。
    • 如果无关更改会导致单条总结失真，请清楚地分开说明，或先询问是否要将它们合并到一条消息中。

  2. 检查差异和上下文。

    • 使用可用的 Git 状态和差异信息，识别所选范围内已暂存、未暂存和未跟踪的更改。
    • 如果无法获取 Git 数据或仓库没有提交记录，请如实说明，并仅根据已提供的上下文起草。
    • 如果有近期提交消息，请参考。除非用户另有要求，否则遵循仓库特定的格式、范围和正文惯例。
    • 对于代码更改，检查周边上下文，确保你要写的每个标题和要点都能对应到具体差异。
    • 对于文档、配置、工作流、资源文件、锁文件或生成文件，应描述其实际影响，而非只列出文件名。
    • 对于二进制、生成或体积很大的文件，应根据文件名、元数据、清单或相邻源代码更改进行总结，而不是倾倒文件内容。
    • 明确指出迁移、环境变量、配置更改、API 或架构更改、数据重写、依赖项更改和手动操作；提及敏感密钥时不得泄露其值。

  3. 选择 Conventional Commit 标题。

    • 有明确范围时，使用 type(scope): summary。
    • 没有明确范围时，使用 type: summary。
    • 有破坏性更改时，使用 type(scope)!: summary 或 type!: summary。
    • 常见类型：feat、fix、docs、refactor、test、chore、perf、build、ci、style、revert。
    • 选择能体现受影响产品领域、包、模块、命令或工作流的范围；不要按文件扩展名选范围，也不要勉强使用不准确的范围。
    • 根据更改的行为意图选择类型，而非根据文件类型。面向用户的修复和功能绝不能归为 chore。新增或有实质变化的指令性文本属于 feat；纠正错误或误导性行为属于 fix；仅作说明的内容才属于 docs。
    • 第一行应简洁。概括主要更改，并在差异明确时说明原因。
    • 使用祈使语气的现在时：fix auth refresh handling，而不是 fixed 或 fixes。
    • 如果用户要求仅提供标题、简短消息或单行消息，则只返回标题。

  4. 撰写正文。

    • 如果标题已经涵盖更改内容，省略正文；对于单一用途的小型差异，通常如此。

    • 对于包含多个部分的差异，默认使用以下基本格式：

      type(scope): <主要更改的简要概述>

- <关键行为、功能、修复或实现更改；必要时说明影响>
- <关键行为、功能、修复或实现更改；必要时说明影响>

    • 优先采用以行为为导向的要点，而不是逐个文件总结。

    • 如果代码层面或业务逻辑方面的影响有助于说明变更的重要性，请予以说明。不要超出差异内容和附近上下文进行推测。

    • 仅当请求、分支名称、差异内容或仓库惯例中包含问题引用时，才添加问题引用。

    • 仅针对迁移、环境变量、手动步骤或运维人员后续操作添加 Required actions:。

    • 对于重大变更，添加 BREAKING CHANGE: 页脚行，以便 Conventional Commit 工具检测。

  5. 完成前进行验证。

    • 确认标题类型与变更的主要意图相符。
    • 确认每个要点都有差异内容作为依据。
    • 确认影响代码的要点描述了用户可见行为、系统行为、契约或有意义的实现影响。
    • 确认重大变更和必需操作分别列出，而不是埋在常规变更要点中。
    • 仅在确实运行过测试时，才声称测试已通过。
    • 返回提交消息文本；如有帮助，可简短提出代为提交。

示例

包含两个页脚的正文：

feat(api)!: require cursor pagination for users

- Replace offset pagination with cursor pagination on the users endpoint
- Add queue configuration for the cursor backfill worker

Required actions:

- Set `CURSOR_BACKFILL_QUEUE` before enabling the worker

BREAKING CHANGE: `GET /users` no longer accepts `page` or `per_page`; clients must send `cursor` and `limit`.

评论

支持 Markdown