| name | git-commit |
| description | 使用中文 Conventional Commit 提交代码。用户要求提交、commit、创建 git commit 或使用 /commit 时触发；先审查状态与 diff，区分本次任务改动和用户已有改动，只暂存相关文件，生成中文提交信息并执行 git commit。 |
Git Commit 中文提交助手
作用
当用户要求“提交一下”“commit”“创建 git commit”或使用 /commit 时，帮助完成一次安全、清晰、可追溯的 Git 提交。
核心目标：
- 只提交本次任务相关改动。
- 使用中文提交说明。
- 保留 Conventional Commits 的类型和作用域结构。
- 不覆盖、不回退、不混入用户已有改动。
- 提交失败时暴露真实错误并协助修复。
提交格式
优先使用单行中文 Conventional Commit：
<type>(<scope>): <中文描述>
示例：
fix(can): 修复 CAN7000 录波保存异常
docs(skills): 更新本地技能同步说明
chore(git): 调整提交助手规则
如果没有明确作用域，可以省略 scope：
docs: 更新技能列表
类型选择
| 类型 | 使用场景 |
|---|
feat | 新增用户可见功能 |
fix | 修复缺陷、异常行为或回归 |
docs | 仅文档、说明、注释类改动 |
style | 格式、空白、排版等不影响逻辑的改动 |
refactor | 既非新增功能也非修复缺陷的代码重构 |
perf | 性能优化 |
test | 新增或调整测试 |
build | 构建系统、依赖、工程配置 |
ci | CI/CD 配置 |
chore | 维护性事务、脚本、工具配置 |
revert | 回滚已有提交 |
工作流程
1. 检查仓库状态
先查看工作区状态和分支：
git status --short --branch
必须识别：
- 哪些文件是本次任务产生的。
- 哪些文件是用户原本已有的改动。
- 是否存在未跟踪文件、删除文件、子仓库改动或大范围无关变更。
如果工作区里有明显无关改动，不要全量暂存；只处理本次任务相关文件。
2. 分析 diff
如果已有暂存内容，优先分析暂存区：
git diff --staged
如果没有暂存内容，分析工作区改动：
git diff
需要判断：
- 改动目的是什么。
- 影响范围是什么。
- 是否应该拆成多个提交。
- 是否包含密钥、Token、私钥、
.env、真实服务器密码等敏感信息。
3. 谨慎暂存
只暂存与本次提交直接相关的文件：
git add path/to/file1 path/to/file2
禁止为了省事执行无差别暂存：
git add .
git add -A
除非用户明确要求“提交全部改动”，否则不要使用全量暂存。
对于大型混合改动，优先建议拆分提交；如果必须从同一文件里挑选部分改动，可以使用交互式暂存：
git add -p
但在自动化环境中，优先采用明确文件路径暂存，避免进入交互式流程。
4. 生成中文提交信息
提交描述应满足：
- 使用中文。
- 简洁说明“做了什么”，不要写空泛词。
- 首行尽量不超过 72 个字符。
- 类型和作用域与实际 diff 对齐。
- 不夸大影响范围，不写未完成事项。
优先从文件路径、模块名、功能点推断 scope。例如：
sync-agent-skills.ps1 -> skillsembeddedskills/can/* -> canembeddedskills/gcc/* -> gccnormalskills/git-commit/* -> git
5. 执行提交
单行提交：
git commit -m "type(scope): 中文描述"
需要补充正文时，使用多条 -m：
git commit -m "type(scope): 中文描述" -m "补充说明改动背景、验证结果或兼容性影响。"
提交后读取结果，向用户说明：
- 提交 hash。
- 提交信息。
- 是否还有未提交改动。
- 是否有未纳入提交的用户改动。
多仓库规则
如果当前任务同时修改了多个独立 Git 仓库，应分仓提交。
每个仓库都要单独执行：
git status --short --branch
git diff
git add <相关文件>
git commit -m "type(scope): 中文描述"
不要跨仓库混淆提交结果。最终回复要分别列出每个仓库的提交 hash。
安全规则
- 不修改 Git 全局配置。
- 不执行
git reset --hard、git checkout -- <path> 等会丢弃改动的命令，除非用户明确要求。
- 不使用
--force、--force-with-lease 推送，除非用户明确要求。
- 不使用
--no-verify 跳过 hook，除非用户明确要求。
- 不 amend 已有提交，除非用户明确要求。
- 不提交密钥、Token、私钥、真实密码或本地敏感配置。
- 不为了让提交通过而删除测试、吞掉错误或隐藏失败信息。
失败处理
如果提交失败：
- 保留真实错误输出。
- 判断是 hook、格式检查、冲突、权限、路径编码还是 Git 状态问题。
- 优先修复根因后重新提交。
- 不要绕过校验，除非用户明确要求。
如果发现当前状态不适合提交，例如无关改动过多、敏感文件已暂存、仓库处于 rebase/merge 冲突中，应先停止并说明原因。
