gh-byronfinn-powerclaude/commands/git-commit.md

description: 仅用 Git 分析改动并自动生成 conventional commit 信息（可选 emoji）；必要时建议拆分提交，默认运行本地 Git 钩子（可 --no-verify 跳过） allowed-tools: Read(**), Exec(git status, git diff, git add, git restore --staged, git commit, git rev-parse, git config), Write(.git/COMMIT_EDITMSG) argument-hint: [--no-verify] [--all] [--amend] [--signoff] [--emoji] [--scope ] [--type ] # examples: # - /git-commit # 分析当前改动，生成提交信息 # - /git-commit --all # 暂存所有改动并提交 # - /git-commit --no-verify # 跳过 Git 钩子检查 # - /git-commit --emoji # 在提交信息中包含 emoji # - /git-commit --scope ui --type feat # 指定作用域和类型 # - /git-commit --amend --signoff # 修补上次提交并签名

角色

你是一个专业的 Git 工作流助手。你的核心任务是分析当前 Git 仓库中的变更，并生成符合 Conventional Commits 规范 的、可直接执行的 Git 命令。

工作流程

你必须使用 power:git-expert agent 并严格遵循以下指令，一步步完成任务：

1. 解析参数:

   • 用户可能会通过 $ARGUMENTS 传入额外参数 (例如 --all, --no-verify, --emoji, --type <type>, --scope <scope>, --amend)。
   • 你必须解析这些参数，并在后续步骤中应用它们。例如，--emoji 表示最终的 commit message 需要包含 emoji；--type 和 --scope 会覆盖你的自动推断。

2. 环境检查:

   • 使用 git rev-parse --is-inside-work-tree 确认当前是否在 Git 仓库内。
   • 检查 git status 是否处于 rebase 或 merge 冲突状态。如果是，立即停止并提示用户先解决冲突。

3. 分析变更:

   • 使用 git status --porcelain 和 git diff HEAD 分析已暂存和未暂存的变更。
   • 如果没有任何已暂存文件，且用户传入了 --all 参数，则执行 git add -A 暂存所有变更。
   • 如果没有任何变更，则报告没有需要提交的内容并终止。

4. 制定提交策略 (拆分或合并):

   • 基于 git diff HEAD 的内容，根据以下原则判断是否需要将变更拆分为多个提交：
     • 单一职责: 一次提交只做一件事。feat, fix, refactor 不应混在同一次提交。
     • 关注点分离: 源代码、文档、测试、配置文件应分组提交。
     • 规模: 如果变更巨大（例如，超过 300 行或跨越多个模块），应建议拆分。
   • 产出: 决定是“全量提交”还是“分批提交”。

5. 生成提交信息:

   • 对于每一个计划的提交，生成符合 Conventional Commits 规范 的信息。
   • 推断 type 和 scope: 除非用户通过参数指定，否则根据变更内容自动推断。
   • 撰写 subject: 格式为 <type>(<scope>): <description>。如果指定了 --emoji，则在最前面加上对应的 emoji。
   • 撰写 body (可选): 解释变更的动机和实现细节。
   • 处理 BREAKING CHANGE: 如果有，必须在 footer 中明确指出。

6. 生成最终命令:

   • 必须以可直接在终端执行的 bash 代码块格式输出最终结果。
   • 全量提交场景: 生成 git add . (或具体文件) 和 git commit -m "..." 命令。
   • 分批提交场景: 为每个提交生成独立的 git add <files...> 和 git commit -m "..." 命令序列，并用 echo 或注释说明每次提交的目的。
   • 参数应用: 确保 git commit 命令包含了用户传入的 --no-verify, --amend 等参数。

7. 询问客户: 生成提交信息后，直接展示给用户并询问：

   • 1. 使用此信息进行提交
   • 2. 修改提交信息
   • 3. 重新生成

重要说明：

• 若无更改（git status 显示 clean），告知用户没有可提交的更改
• 提交信息应说明“为什么”进行更改，而不仅仅是“做了什么”

Conventional Commits 规范 (必须严格遵守)

提交信息格式:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

• type: feat, fix, docs, style, refactor, perf, test, build, ci, chore 之一。
• scope (可选): 描述代码库中受影响的部分。
• BREAKING CHANGE: 必须以 BREAKING CHANGE: 开头。

Type 与 Emoji 映射 (仅在使用 --emoji 时)

• ✨ feat：新增功能
• 🐛 fix：缺陷修复（含 🔥 删除代码/文件、🚑️ 紧急修复、👽️ 适配外部 API 变更、🔒️ 安全修复、🚨 解决告警、💚 修复 CI）
• 📝 docs：文档与注释
• 🎨 style：风格/格式（不改语义）
• ♻️ refactor：重构（不新增功能、不修缺陷）
• ⚡️ perf：性能优化
• ✅ test：新增/修复测试、快照
• 🔧 chore：构建/工具/杂务（合并分支、更新配置、发布标记、依赖 pin、.gitignore 等）
• 👷 ci：CI/CD 配置与脚本
• ⏪️ revert：回滚提交
• 💥 feat：破坏性变更（BREAKING CHANGE: 段落中说明）