菜单
Git 提交信息智能生成工具。基于 Claude 对代码改动和用户意图的深度分析，自动生成符合项目规范的 commit message，支持四层验证机制确保质量。 Use when this capability is needed.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/tomevault-io/skills-registry --skill git-commit-writer命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | git-commit-writer |
| description | Git 提交信息智能生成工具。基于 Claude 对代码改动和用户意图的深度分析，自动生成符合项目规范的 commit message，支持四层验证机制确保质量。 Use when this capability is needed. |
| metadata | {"author":"fsyyft-go"} |
基于 Claude 智能分析的 Git 提交信息（commit message）生成工具，100% 大模型驱动，无需脚本。
核心特点：
工作原理： Claude 分析 git diff + 用户上下文 → 自动判断类型和范围 → 生成符合规范的 commit message → 四层严格验证 → 输出最终结果
# 默认：针对当前暂存区中的文件生成 commit message
"帮我为暂存的改动生成 commit message"
"分析暂存区并生成 commit"
# 如果没有暂存区，但有未提交的文件
"为未提交的改动生成 commit message"
"分析当前工作区的改动"
# 指定分支：对比指定分支的所有变更
"为 develop 分支的变更生成 commit message"
"分析相对于 feature/skill 分支的所有改动"
"对比 master 分支，生成合并 commit message"
# 结合 git diff 和用户上下文
"我为 web 服务添加了用户认证功能，帮我生成 commit message"
"修复了 data 层的数据库连接问题，生成 commit message"
用户输入分析
↓
判断用户是否指定分支？
├─ 是 → 进入分支对比模式
│ ├─ 运行: git diff <target-branch> --name-only
│ ├─ 运行: git diff <target-branch>
│ └─ 获取所有变更文件和具体改动内容
│
└─ 否 → 进入默认模式
├─ 检查暂存区（git diff --staged --name-only）
│ ├─ 有暂存文件 → 进入暂存区模式
│ │ ├─ 运行: git diff --staged
│ │ └─ 分析暂存的改动内容
│ │
│ └─ 无暂存文件 → 进入未提交文件模式
│ ├─ 运行: git diff --name-only
│ ├─ 运行: git diff
│ └─ 分析未提交的改动内容
│
└─ 收集用户提供的上下文和意图说明
暂存区模式：
运行 git status → 确认暂存状态
运行 git diff --staged --name-only → 获取变更文件列表
运行 git diff --staged → 分析具体改动内容
识别文件类型和路径
未提交文件模式：
运行 git status → 确认工作区状态
运行 git diff --name-only → 获取变更文件列表
运行 git diff → 分析具体改动内容
识别文件类型和路径
分支对比模式：
运行 git status → 确认当前分支
运行 git diff <target-branch> --name-only → 获取变更文件列表
运行 git diff <target-branch> → 分析具体改动内容
识别文件类型和路径
识别变更涉及的 commit 数量和历史
共同步骤：
收集用户提供的上下文说明和改动意图
统计改动规模（文件数量、行数变化）
识别改动的关键特征
分析改动类型（新功能/bug修复/重构/文档等）
识别影响范围（web/task/api/internal 等）
提炼核心业务意图
判断改动的重要性和影响程度
识别与现有功能的关系
选择合适的 commit type（feat/fix/docs 等）
确定准确的 scope（标准范围或路径范围）
提炼简洁的中文描述（祈使句、首字母小写、不加句号）
生成完整的 commit message 格式
第一层：格式验证
<类型>(<范围>): <描述> 格式第二层：类型-范围一致性验证
第三层：语言和语法验证
第四层：代码改动一致性验证
直接输出最优的 commit message
提供简要的改动分析说明
标注验证通过的所有层级
验证原则：四层验证必须全部通过，任何一层不通过都必须调整。
验证规则：必须符合 <类型>(<范围>): <描述> 格式
正则表达式：^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\([^)]+\))?: .+$
通过条件：
<类型>: <描述>）不通过示例：
添加用户功能（缺少类型）Feat: 添加用户功能（类型大写）feat(web)（缺少描述）类型-范围映射表：
| 类型 | 推荐范围 | 可接受范围 | 不可接受范围 |
|---|---|---|---|
| feat | api, web, task, internal, .claude/skills/* | docs | test, build |
| fix | data, biz, service, server, web, task | internal | docs, build, ci |
| docs | 任意范围（包含具体路径） | - | - |
| style | internal, biz, service, data | - | api, docs |
| refactor | internal, biz, service, data, server | - | docs, test |
| perf | data, biz, service | internal | docs, test |
| test | biz, service, data | internal | docs, api |
| build | Makefile, go.mod, dockerfile | - | internal, biz |
| ci | .github/, .gitlab-ci. | - | internal, biz |
| chore | 任意范围（维护性工作） | - | - |
| revert | 与原 commit 相同的范围 | - | - |
通过条件：类型和范围必须在上表中匹配
不通过示例：
test(api): 添加接口测试（test 不应在 api）feat(docs): 添加新功能（feat 应在代码文件）中文表述规范：
通过条件检查：
不通过示例：
feat: 添加了用户管理功能（使用"了"）fix: 修复数据连接的问题（"的"字冗余）feat: 添加用户功能。（结尾有句号）feat: 搞定数据库连接（口语化）验证方法：对比生成的 message 与实际 git diff 内容
通过条件：
message 描述的改动类型与 diff 内容一致
message 指定的范围与 diff 中变更的文件路径一致
message 描述的功能与 diff 内容匹配
没有遗漏重要信息
不通过示例：
验证流程控制：
第一层验证 → 通过 → 第二层验证 → 通过 → 第三层验证 → 通过 → 第四层验证 → 通过 → 输出
↓ ↓ ↓
不通过 不通过 不通过
↓ ↓ ↓
调整格式 调整类型/范围 优化语言 完善描述
↓ ↓ ↓
重新验证 重新验证 重新验证 重新验证
标准范围：web, task, api, internal, docs, build, ci, chore
路径范围：点号分隔的路径（如 .claude/skills/go-import-enforcer）
Q: 如何处理多种类型的改动？
A: 识别主要改动类型：
Q: 改动涉及多个范围怎么办？
A: 分析改动涉及的模块：
Q: 如何描述重构性改动？
A: 判断改动本质：
Q: 如何避免描述过于笼统或过于细节？
A: 提炼核心意图：
详细的 commit 规范、丰富示例和决策流程，请参考：
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
基于 SOC 职业分类
