用途：在需要提交 Git 改动时，帮助生成格式统一、语义清晰的原子提交，并按 conventional commit 规范添加 emoji 前缀。
主要能力：先运行 git status 评估仓库状态，遇到未解决的合并冲突或无任何改动时中止并提示用户；通过 git log --oneline -5 了解项目既有提交风格，用 git diff --staged 或 git diff 查看改动，未跟踪文件用 Read 查看内容。随后按类型（feat/fix/refactor/docs 等）与关注点对文件分类分组，依据拆分规则（不同目的、无关子系统、源码与无关文档混在一起、超过约 200 行且关注点可分离、格式与逻辑改动混合）和保持规则（功能/修复与其测试、代码与其类型定义、同一符号的多文件重命名、代码与描述该代码的文档）形成原子单元。
使用方式：单个逻辑单元直接 git add 指定文件后提交；多个逻辑单元先展示分组计划并等待用户确认，再按基础改动优先逐个暂存并提交。提交格式为 <emoji> <type>: <description>，使用祈使语气、主题行不超过 72 字符、冒号后小写，可用 git commit -m 添加正文。破坏性改动用 💥、生产热修复用 🚑️、安全修复用 🔒️ 覆盖基础 emoji。最后用 git log --oneline -3 校验格式，并用 git status 确认无遗留改动。
限制：必须使用显式文件路径，禁止 git add -A 或 git add .；不得暂存 .env、凭据、密钥、令牌等敏感文件；提交失败时不得使用 --amend，应重新创建新提交；二进制文件只记录上下文不分析差异；超过 500 行的大改动集始终建议拆分。若用户已描述改动意图，以其为主要参考但需与实际 diff 核对。