mcpField
C
commit-summary

commit-summary

github.com/shipshitdev开发38104 次安装2 天前更新
代码仓库

关于 commit-summary

commit-summary 是用于根据实际 Git 差异生成 Conventional Commits 候选信息的技能，面向需要清晰拆分和审查提交的开发者。只有在获批后才会暂存或创建提交。

主要功能

  1. 01检查暂存与未暂存差异
  2. 02建议提交类型和作用域
  3. 03识别混合变更并建议拆分
  4. 04检查敏感文件与破坏性变更
  5. 05获批后暂存或创建提交

适用场景

  1. 01为代码变更拟定 Conventional Commit 信息
  2. 02将无关改动拆分为独立提交

安装

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

$npx skills add https://github.com/shipshitdev/skills --skill commit-summary

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

包含的文件

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

plugin.json
README.md
licenses/
LICENSE
LICENSE-cursor-team-kit
LICENSE-superpowers
NOTICE.txt

详细介绍

提交摘要

根据实际 Git 差异生成准确的 Conventional Commits。

授权范围

只能在用户请求和现有批准范围内操作；加载此技能不会赋予任何新权限。仅报告的请求必须只报告，遵守调用方指定的目标、主机、提供方和成本限制，扩展范围前须先询问，并将这些限制告知委派对象。

约定

输入：

  • 仓库根目录
  • 已暂存的更改、未暂存的更改，或已批准暂存的路径
  • 可选的提交类型、范围和破坏性更改上下文

输出：

  • 候选提交消息
  • 更改混杂时的逻辑提交分组
  • 经批准后创建的提交哈希（如有请求）

创建/修改：

  • 仅生成消息模式下不做任何更改
  • 经批准后可暂存文件并创建提交

外部副作用：

  • 除非后续工作流推送该提交，否则无

需要确认：

  • 暂存文件前
  • 创建提交前
  • 修改或压缩现有提交前

委派给：

  • 当提交需要推送并创建 PR 时，委派给 github-pr-publish
  • 当差异中出现机密或敏感文件时，委派给 git-safety

工作流

  1. 检查仓库状态：

    git status -sb
git log --oneline -5
git diff --stat
git diff --cached --stat

  2. 确定更改是否已暂存：

    • 如果存在已暂存的更改，根据 git diff --staged 生成消息。
    • 如果没有暂存任何内容，检查未暂存的更改并提出逻辑分组。
    • 如果混有无关更改，建议拆分为多个提交。

  3. 防止不安全的提交：

    • 不要暂存机密、.env、凭据、私钥、本地数据库、构建缓存或大型生成产物。
    • 如果出现敏感文件，请停止并委派给 git-safety。
    • 除非功能或修复所必需，否则不要在功能/修复提交中包含无关的格式改动。

  4. 选择 Conventional Commit 类型：

    • feat：面向用户的功能或能力
    • fix：错误修复
    • docs：仅文档更改
    • style：仅格式调整，不改变行为
    • refactor：重构代码，不改变行为
    • perf：性能改进
    • test：仅测试
    • build：构建系统、包管理器、依赖项
    • ci：CI/CD 工作流更改
    • chore：不影响用户可见行为的维护工作
    • revert：撤销先前的提交

  5. 确定范围：

    • 优先使用历史记录中已有的包、应用、领域或子系统名称。
    • 如果范围过于笼统（misc、stuff、changes），则省略范围。

  6. 检测破坏性更改：

    • 公共 API 合约更改
    • CLI 标志或输出更改
    • 需要用户采取操作的数据库/架构迁移
    • 移除配置键、环境变量、路由、事件或导出符号

    格式为 type(scope)!: summary，并包含 BREAKING CHANGE: 页脚。

  7. 生成提交消息：

    type(scope): imperative summary

Optional body explaining why and any non-obvious implementation detail.

Optional footer such as:
BREAKING CHANGE: migration required because ...
Refs: #123

  8. 如果用户要求提交，展示完整的确切消息，并在授权范围内继续操作。只有当所选文件或操作超出请求范围时，才需征求批准：

    git add <approved-paths>
git diff --staged --stat
git commit -m "<subject>" -m "<body-or-footer>"

质量标准

  • 标题使用祈使语气，且少于 72 个字符。
  • 如果仅凭差异不足以说明原因，则在正文中解释原因。
  • 消息不得夸大实际行为。
  • 每个提交只包含一个逻辑更改。
  • 除非仓库惯例要求，否则不要在提交消息中写入验证命令。

注意事项

  • git add . 可能会暂存不需要的文件。 如果 .gitignore 未排除 node_modules、.env* 或构建产物，请始终优先使用 git add <specific-paths>。提交前，使用 git diff --staged --stat 进行检查。
  • Breaking-change 页脚区分大小写。 对于 semantic-release 和 conventional-changelog 等工具，标记必须准确写为 BREAKING CHANGE:（包含一个空格且全部大写），才能被识别。BREAKING-CHANGE: 并不等同于它。
  • 修正提交会改写历史。 切勿修正已推送到共享分支的提交。如果该提交已存在于远程仓库，请改为创建一个新的修复提交。
  • Co-authored-by 页脚可能与仓库规范冲突。 有些仓库（包括本项目）明确禁止使用 Co-Authored-By 页脚。添加之前，请检查仓库的 Agent 指令文件（AGENTS.md、CLAUDE.md 或同类文件）或近期提交历史，了解项目规范。

示例

  • feat(auth): add password reset flow
  • fix(api): handle null provider response
  • ci(actions): restrict pull request token permissions
  • refactor(utils): extract date formatting helper
  • docs: update GitHub project board workflow

评论

支持 Markdown