| name | git-commit |
| description | 生成规范的 Git 提交信息并直接提交。当用户说"提交"、"commit"、"帮我提交"、"git commit"、"写个 commit"、"提交一下"、"生成 commit message"、"/commit" 时立即触发。 工作流程：先查看暂存区文件（若为空则查看工作区变更文件），为每个文件分析"为什么改"和"怎么改的"，以此为内容生成提交信息，最后直接执行 git commit。 |
Git Commit Skill
目标
若用户说提交哪些内容就提交哪些内容
查看用户说要提交的内容，若无说明就是暂存区优先 → 逐文件分析 Why & How → 生成提交信息 → 直接执行提交。
Step 1 — 获取变更文件列表
查看用户说要提交的内容若无说明就是优先查看暂存区：
git diff --cached --name-only
- 如果输出不为空 → 使用暂存区文件，继续 Step 2
- 如果输出为空 → 改为查看工作区变更：
git diff --name-only
git status --short
- 如果三者均为空 → 告知用户"没有可提交的变更"，终止。
注意：若最终决定使用工作区文件（非暂存），需先 git add 对应文件再提交。
若存在 untracked 文件，询问用户是否一并纳入提交，再决定是否 git add。
Step 2 — 逐文件读取完整 diff
根据上一步确定的来源，对每个文件单独获取 diff：
git diff --cached -- <file>
git diff -- <file>
对于二进制文件或自动生成文件（如 package-lock.json、*.min.js、图片等），记录文件名即可，无需逐行分析。
若单个文件 diff 超过 300 行，先看 --stat 概要，再重点阅读关键改动区域，不必逐行穷举。
Step 3 — 逐文件分析 Why & How
对每个文件，基于 diff 内容，写出：
- Why（为什么改）：这次修改的动机/目的，例如"修复登录超时 bug"、"支持多语言"、"提升可读性"
- How（怎么改的）：具体做了什么操作，例如"将硬编码的超时时间提取为可配置常量"、"新增
getLocale() 方法"
要求：
- 基于真实 diff，不要猜测或编造
- 说明"意图"，而非重复描述 diff 本身
- 语言与用户请求语言一致（中文请求 → 中文分析）
Step 4 — 生成提交信息
提交信息格式如下：
{emoji} {type}({scope}): {整体变更的一句话摘要（≤72字符，祈使句，不加句号）}
{file1}
- Why: {为什么改}
- How: {怎么改的}
{file2}
- Why: {为什么改}
- How: {怎么改的}
...
Type / Emoji 对照表：
| type | emoji | 场景 |
|---|
| feat | ✨ | 新增功能 |
| fix | 🐛 | 修复 bug |
| refactor | ♻️ | 重构（不影响功能） |
| style | 🎨 | 格式/样式调整 |
| docs | 📝 | 文档变更 |
| test | ✅ | 测试相关 |
| perf | ⚡️ | 性能优化 |
| chore | 🔧 | 配置/依赖/杂项 |
| ci | 👷 | CI/CD 相关 |
| build | 📦 | 构建系统/外部依赖 |
| security | 🔒 | 安全修复 |
| wip | 🚧 | 进行中（临时提交） |
Scope：填写受影响的模块/目录，如 auth、api、ui；跨多模块可省略。
若项目 git log 中使用了特定 commit 风格（含或不含 emoji、使用特定 scope 命名），则沿用该风格。
Step 5 — 执行提交
无需等待用户确认，直接使用 HEREDOC 执行提交：
git commit -m "$(cat <<'EOF'
{完整提交信息粘贴于此}
EOF
)"
提交完成后运行：
git log --oneline -1
向用户展示提交 hash 和摘要，确认提交成功。
注意事项
- 绝不编造：未获取到 diff 内容的文件，不得凭空写分析
- 绝不提交敏感文件：检测到
.env、含 secret/token/password/key 字样的文件，跳过并告警
- 暂存区优先：有 staged 文件就只提交 staged，不混入工作区未暂存的内容
- 不拆分提交：本 skill 目标是一次性提交所有目标文件，如用户需要拆分请明确提出
