用途：把请求的改动转化为一个或多个干净的 Git 提交，避免夹带无关工作。来源为 legendapp/legend-skills 下的 commit 技能。
主要能力：按范围控制提交内容；区分直接模式与计划模式；按单一概念分组提交；生成符合 Conventional Commit 的提交信息。
范围规则：默认只提交当前智能体在本次任务中产生的改动，依据已知起始状态、对话与工具历史判断归属；仅在用户明确要求提交全部或整个工作树时才检查并提交整棵树；用户指定的文件、代码块、提交或排除项需遵守；仅用于排查的诊断、日志、追踪、性能输出、实验开关、截图和复现夹具等临时产物应排除，永久回归测试保留，不确定时询问。若归属或边界无法可靠确定，应在暂存前停止并询问，禁止凭猜测包含既有、并发或用户自己写的改动。
审批模式：直接模式——用户要求提交时，分析范围并直接创建所需提交，无需另行确认；计划模式——用户要求先计划、先审查提交、要求等待或先提示批准时，先给出提交计划，等待如 go 的明确批准再暂存或提交，批准后按约定完成；澄清停止——任何模式下，若归属不清、混合代码块无法安全暂存、仓库指引与请求冲突或分组意图不明，先停止提交。
检查步骤：先阅读 AGENTS.md、贡献文档或可见提交约定；依据明确上下文、已批准的任务文档、已验证的问题 URL 或仓库元数据判断是否修复已知 GitHub issue，不能仅凭偶现编号推断；用 git status -sb、git diff --stat、git diff --staged --stat 及针对性 git diff、git diff --staged 检查状态，暂存前查看相关未跟踪文件；把已暂存、未暂存和未跟踪改动分类为范围内或范围外；保留范围外的已暂存改动，若同路径混有无关代码块且无法安全隔离，应停止询问。
分组与提交信息：按一个连贯概念分组，如功能、修复、重构、测试、文档、配置、依赖或子系统；文件内无关改动用 git add -p 或路径/代码块限定方式拆分。默认信息风格为 Conventional Commit 的 type: subject，不用作用域括号，祈使语气、具体主题、结尾不加句号，除非用户明确要求不加 Co-authored-by 尾注；修复已验证 issue 时在主题末尾追加 #<编号>。主题应命名具体行为与目标，避免 improve behavior、update handling 等模糊表述。
提交与报告：每组仅暂存该组，保持范围外的暂存项不被静默取消；用 git diff --staged --stat、针对性 git diff --staged 和 git diff --staged --check 验证；钩子运行后重新检查工作树再继续下一组；完成后报告提交哈希与剩余未暂存文件，若提交失败则停止并报告确切失败与当前 git 状态。涉及收费、平台等信息暂未提供。