创建清晰且突出变更价值的 Git 提交信息。当用户要求提交或保存暂存区/非暂存区的修改，并希望使用符合当前仓库规范且能清晰表达价值的提交信息时使用。
Git Commit
根据当前工作区的改动，精心打磨并生成一次 Git 提交。
上下文收集（Context）
依次将以下命令作为独立的 Shell 工具调用来收集工作区上下文——即单次 argv 风格的调用（仅包含程序及其参数）。切勿使用 ;、&&、||、管道、$(...) 或 2>/dev/null 重定向拼接命令：此类语法仅支持 POSIX Shell，在 Windows PowerShell 下会直接报错中断。直接读取每个命令的退出状态码——非 0 退出属于需要解读的正常状态，而非需要静默屏蔽的错误。
| 命令 | 用途 | 返回非 0 或输出为空意味着 |
|---|---|---|
git status |
工作区状态 | 非 Git 仓库——向用户汇报并终止执行 |
git diff HEAD |
未提交的改动 | 尚未进行首次提交的空仓库（Unborn repo）——将所有已追踪改动视为新建 |
git branch --show-current |
当前分支 | 输出为空 = 处于游离头指针（detached HEAD）状态 |
git log --oneline -10 |
历史提交风格 | 尚未进行首次提交的空仓库——暂无历史风格可参考 |
git rev-parse --abbrev-ref origin/HEAD |
远程默认分支 | 未设置 origin/HEAD——按步骤 1 解析默认分支 |
这些数值是执行任何操作前截取的快照。在正式提交前，务必立即重新读取关键状态（如当前分支、已暂存文件集），因为从收集上下文到实际执行提交之间，工作区随时可能发生变化。
执行流程（Workflow）
步骤 1：收集上下文
分别作为独立的 Shell 工具调用，运行上述上下文收集章节中的命令（git status、工作区 diff、当前分支、近期提交、远程默认分支）。
远程默认分支返回的值通常类似于 origin/main。剥离 origin/ 前缀即可获得分支名称。如果该命令返回非 0 退出码（即未设置 origin/HEAD）或仅返回孤立的 HEAD，请尝试运行：
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
若两者均失败，则回退保底使用 main。
如果 git status 显示工作区很干净（没有已暂存、已修改或未追踪的文件），直接汇报无可提交内容并终止流程。
如果当前分支名称为空，说明仓库处于游离头指针（detached HEAD）状态。如果用户希望将本次修改挂载到某个分支上，请向用户说明提交前需要先创建分支，并询问现在是否要新建一个特性分支（feature branch）。请使用当前平台提供的阻塞式提问工具：在 Claude Code 中使用 AskUserQuestion（若未加载 schema，请先调用 ToolSearch 并指定 select:AskUserQuestion）；在 Codex 中使用 request_user_input；在 Antigravity CLI (agy) 中使用 ask_question；在 Pi 中使用 ask_user（需要 pi-ask-user 插件）。只有在宿主环境中不存在任何阻塞式提问工具，或者工具调用报错（例如 Codex 的编辑模式）时，才回退到在聊天中展示选项——切勿仅因需要加载 schema 就选择回退。绝不要静默跳过提问。
- 若用户选择创建分支，根据修改内容提炼出分支名，执行
git checkout -b <branch-name>创建分支，随后重新运行git branch --show-current，并将结果作为后续流程中的当前分支名。 - 若用户拒绝创建，则直接在游离头指针状态下继续执行提交。
步骤 2：确定提交信息规范
按照以下优先级判定：
- 上下文中的现有仓库规范 —— 如果已加载的项目指令（如
AGENTS.md、CLAUDE.md或类似文件）中明确规定了提交信息规范，请直接遵循。无需重复读取这些文件；它们已在会话启动时加载。 - 近期提交历史 —— 若未配置显式规范，检查步骤 1 中获取的最近 10 条提交记录。若存在清晰的模式（例如 Conventional Commits、带 Ticket 前缀、带 Emoji 前缀等），则匹配该模式。
- 默认规范：Conventional Commits —— 若上述来源均未提供模式，默认采用 Conventional Commit 格式：
type(scope): description，其中 type 为feat、fix、docs、refactor、test、chore、perf、ci、style、build之一。
使用 Conventional Commits 时，请选择能最精准描述本次改动的 type（参考上述列表）。当 fix: 和 feat: 似乎都适用时，优先默认选 fix:：补救失效行为或缺失行为的改动属于 fix:，即使它是通过新增代码实现的也不例外。feat: 仅保留给用户此前无法完成的新功能/新能力。其他类型在更契合时仍作为首选。用户亦可显式覆盖指定类型。
步骤 3：合理划分逻辑提交
在将所有修改打包暂存之前，先扫描变动文件，梳理出天然独立的关注点。如果修改的文件能清晰地归纳为不同的逻辑变更（例如某一目录下的代码重构与另一目录下的新功能开发，或者源文件修改与无关功能的测试文件），请为每组变更分别创建独立的提交。
保持轻量化原则：
- 仅在文件层级进行分组 —— 切勿使用
git add -p或尝试拆分单个文件内部的块（hunks）。 - 划分依据要显而易见（如不同的功能模块、互不相关的 Bug 修复）时再拆分；若界限模糊，合并为一个提交即可。
- 拆分为 2 到 3 个逻辑提交最为适宜。切勿过度切割成堆积如山的微型提交。
步骤 4：暂存与提交
若上述上下文中的当前分支为 main、master 或步骤 1 中解析出的默认分支，提交前须自动创建一个特性分支。根据修改内容提炼出分支名，运行 git checkout -b <branch-name> 新建分支，运行 git branch --show-current 确认，并将新分支作为后续流程中的当前分支。无需询问是否建分支 —— 禁止直接在默认分支上提交。
撰写提交信息：
- 主题行（Subject line）：简洁精炼、采用祈使语气，重点说明为什么修改而非修改了什么。遵循步骤 2 中确定的规范。
- 正文（Body）（非必要不添加）：对于非琐碎的复杂变更，空一行后添加正文。解释修改动机、权衡考量，或任何未来阅读者需要的背景信息。对于意图一目了然的单一变更，省略正文。
对于每一个提交分组，在单次调用中完成暂存与提交。优先按文件名暂存具体文件，而非使用 git add -A 或 git add .，以防误带入敏感文件（如 .env、密钥凭证）或无关修改。使用 heredoc 保持格式完好：
git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
type(scope): 填写主题行
可选的正文内容，用于解释做此修改的原因，
而不仅仅是改了哪些代码。
EOF
)"
步骤 5：确认结果
提交完成后运行 git status 验证是否成功。汇报提交哈希（commit hash）与对应的主题行。
