القائمة
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
استنادا إلى تصنيف SOC المهني
| 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.