用途
smart-git-commit 用于把当前工作区中已经发生的改动整理成一组原子提交。它只做分组和暂存这两件事，不会在提交过程中修复 lint、重新格式化或改动文件内容；如果 diff 中暴露出其他问题，会在汇报时提及，而不是顺手修改。
主要能力
- 检查改动：并行运行 git status、git diff、git diff --cached、git log --oneline -10，了解所有已修改/未跟踪文件、未暂存与已暂存改动，以及仓库自身的提交约定（scope、区域名称）。如果没有可提交内容，会说明并停止。
- 按区域分组：把改动拆成原子提交，每个提交对应一个逻辑变更。按子系统或顶层目录分组（如 api/、docs/、.github/workflows/、某个服务、某个模型层）；属于同一逻辑变更的测试和文档会与改动放在一起；区域名称取自仓库自身约定（近期提交主题、CLAUDE.md、README），而不是自创；难以归类的文件并入最相关的组；已暂存文件也按同样方式重新分组暂存。完成标准是 git status 中每个改动文件恰好归入一个组，且没有组跨越两个不相关的顶层区域。
- 确定提交类型：按组选择 feat（新功能、模型、端点、工作流）、fix（缺陷修复、逻辑纠正、修复失败的测试）、docs（仅文档）、refactor（不改变行为的重构）、test（新增或更新测试）、chore（配置、依赖、CI/CD、工具）、style（格式、空白，无逻辑变化）。如果近期提交使用 scope（如 feat(api): …），沿用相同 scope；否则使用裸类型。即使仓库历史不符合规范，也始终生成 Conventional Commits。
- 逐组提交：对每组只暂存其文件并提交，命令为 git add <files in group> 与 git commit -m "$(cat <<'EOF' … EOF)"。提交信息规则：小写类型前缀；祈使语气（add、fix、update，而非 added、fixes）；主题行最多约 72 字符；主题行末尾不加句号；仅当 why 不明显时才写正文；信息中任何位置都不使用破折号，改用逗号、冒号、括号或改写句子。示例：feat: add customer metrics endpoint、fix: handle null totals in order aggregation、docs: document retry behavior for ingestion jobs、refactor: simplify date-parsing helpers、test: cover empty-cart checkout path、chore: update CI workflow schedule。
- 按需推送：所有提交创建后，确认 git status 干净，确保没有改动文件被静默遗漏。仅当请求明确要求推送时才推送（用户说“push”“commit and push”“push it”，或调用方技能的工作流包含推送）；单纯的“commit”到此为止，提交保留在本地。推送使用 git push；若分支尚无上游，使用 git push -u origin HEAD。推送需在沙箱外运行，因为 git push 需要网络访问，沙箱 shell 会阻止它，失败会表现为类似 DNS/连接错误，看起来像认证或远程问题；若推送因连接错误失败，应首先怀疑沙箱。结束时先给出结果：提交主题以及推送是否成功，或说明未推送，一两行即可，不做逐提交的详细说明。
适用场景
当用户要求提交改动时使用，尤其适合希望把混杂的工作区改动整理成按区域划分、符合 Conventional Commits 规范的多个原子提交，并且只在明确要求时才推送的场景。
限制与安全规则
以下规则每次运行都生效，因为每条要么不可恢复，要么会把问题转嫁给他人：
- 不修改已经推送过的提交；重写共享历史会破坏该分支的其他所有检出。
- 不强制推送到 main 或 master，也不跳过钩子（--no-verify）；钩子是仓库的门禁，不是障碍。
- 不提交可能包含密钥的文件（.env、凭据、令牌）；已推送的密钥即使之后删除也已被泄露。
- 如果 git push 被拒绝（非快进），停止并告知用户，而不是强制推送。
关于收费、价格、平台支持等具体信息，资料中暂未提供。