关于 git:commit
git:commit 是用于准备并创建 Git 提交的技能。它检查目标暂存内容，根据差异拟定便于审阅的提交信息，并在不打开编辑器或使用交互式 Git 流程的情况下提交。
主要功能
- 01处理仅暂存区和 HEAD 范围
- 02暂存并核实整个工作树
- 03检查差异和仓库背景
- 04拟定便于审阅的提交信息
- 05以非交互方式创建提交
适用场景
- 01仅提交已暂存的更改
- 02使用 HEAD 范围提交整个工作树
- 03在提交信息中准确概括更改
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/git:commit确认已加载。
附带文件agents/openai.yaml
详细介绍
创建 Git 提交
概述
准备正确的暂存变更集，起草提交消息，并使用该消息创建提交。 只有在提交消息完全确定后，才创建提交。不要打开编辑器，也不要依赖交互式 Git 流程。
工作流
1. 确定支持的范围
此技能仅支持两种范围模式：
- 不带参数的技能
git:commit首先将提交目标视为当前仅包含已暂存内容的集合。 如果暂存差异非空，则保持保守的仅提交已暂存内容的行为，并继续处理暂存差异。 如果暂存差异为空，则将不带参数的调用解释为隐式请求提交整个工作树，并自动将流程切换到HEAD模式。 - 带
HEAD的技能git:commit先使用git add -A暂存整个工作树。 暂存后，确认没有未暂存的已跟踪变更或未跟踪文件。
此技能有意不支持提交范围，例如带有 <commit> 的技能 git:commit。
2. 安全地准备提交集
对于技能 git:commit：
- 使用
git diff --staged检查索引。 - 如果暂存差异非空，则将提交范围限定为索引，并忽略未暂存的变更。
- 如果暂存差异为空，不要立即停止。将工作流切换到与带
HEAD的技能git:commit相同的准备流程，因为用户可能为了方便而省略了HEAD。
对于带 HEAD 的技能 git:commit：
- 运行
git add -A。 - 继续操作前，确认工作树现已全部暂存。
- 优先使用
git status --porcelain进行验证，并确认没有任何条目带有未暂存工作树标记，也没有未跟踪条目。 - 如果验证失败，则停止并说明哪些内容仍不在提交范围内，不要提交部分结果。
- 如果运行
git add -A后暂存差异为空，则停止并说明没有可提交的内容。
将隐式回退视为对用户体验的优化，而不是对显式范围的重新定义。仅在不带参数的技能 git:commit 中应用。
3. 围绕差异构建上下文
使用第 2 步准备好的暂存集，在编写任何内容之前围绕它构建上下文。相关差异取决于第 2 步的结果：仅暂存模式下使用 git diff --staged，HEAD 模式下则使用运行 git add -A 后相对于 HEAD 的整个工作树差异。
使用轻量级 Git 上下文来改进判断，不要让它凌驾于差异之上：
- 通过差异本身检查文件路径、代码块内容和大致规模。
- 在可能揭示意图时，使用
git branch --show-current检查当前分支名称。 - 如果有助于区分已暂存与未暂存的工作，可选择检查
git status --short。
仅将分支名称视为弱提示。忽略无法说明变更内容的模糊名称或工单 ID。
4. 推断与评审相关的变更要点
从差异出发，按顺序回答以下三个问题。问题 1 是关于仓库的事实；问题 2 和 3 是对具体变更的判断。
- 此仓库实际交付什么？ 在分类任何内容之前，先确定哪些内容构成仓库的产品范围。同一份差异可能因答案不同而体现出截然不同的意图。
- 以代码为核心的仓库交付可执行产物（二进制文件、库、服务、应用）。
- 以内容为核心的仓库将 Markdown、提示词、架构、配置包、设计文档或类似内容本身作为产品交付。
- 以基础设施为核心的仓库交付 Terraform 模块、Helm charts、CI 流水线或其他运维资源。
- 用户的主要意图是什么？
- 哪些次要变更会实质影响评审，值得重点说明？
4a. 通过决策树分类主要意图
第一道判断：此更改是否修改了问题 1 中定义的仓库交付产品界面？
- 是 — 按顺序遍历影响产品的分类链，并采用第一个匹配的类型。该分类链按照对审阅者的重要程度排序，因此较强的意图优先于较弱的意图；
refactor是兜底类型，适用于产品界面上不属于任何前述类型的所有更改。feat：此更改是否为产品界面新增了用户可见的功能？- 是：使用
feat。 - 否：继续。
- 是：使用
fix：此更改是否修复了产品界面中的缺陷？- 是：使用
fix。 - 否：继续。
- 是：使用
perf：此更改是否在不改变外部行为的情况下，改善了产品界面的性能特征？- 是：使用
perf。 - 否：继续。
- 是：使用
style：此更改是否仅涉及产品界面的格式或空白字符，且不改变行为？- 是：使用
style。 - 否：继续。
- 是：使用
test：此更改是否仅涉及随产品界面一起交付的测试或测试固件？- 是：使用
test。 - 否：继续。
- 是：使用
refactor：兜底 — 此更改在不改变外部行为的情况下重构了产品界面，且不符合以上任何类型。使用refactor。
- 否 — 此更改仅涉及支持性材料。根据材料的性质选择相符类型：
docs：更改文档、注释或说明性文字，这些内容用于支持交付产品，但本身并非交付产品。chore：更改构建、CI、元数据、工具、维护或其他附属材料。
请谨慎应用以下消歧规则：
- 在内容优先型仓库中，交付界面上新增的实质性终端用户内容属于产品更改，因此应归为
feat（或视情况归为fix/refactor/等），而不是docs。docs仅用于本身并非产品的支持性文字。 - 在代码优先型仓库中，源文件中仅修改注释属于支持性文字，因此应归为
docs，而不是代码更改类型。 - 不要仅因为差异较大或涉及许多文件，就将更改提升为
feat。只有当更改确实为产品界面新增了用户可见的价值时，才使用feat。 - 如果单个提交确实同时涵盖决策树两部分的内容，请选择能体现主要审阅关注点的类型，并通过正文和次要更改亮点说明其余内容。
4b. 按审阅价值排列次要更改
然后按审阅价值排列次要更改。仅突出显示能切实帮助读者浏览 git log 的更改，例如：
- 公共 API 结构更改
- 模块或目录重组
- 架构或契约更改
- 影响范围较大的跨领域清理
- 值得注意的配置或工作流更改
- 迁移、移除或影响兼容性的编辑
降低低信号附带更改的优先级，例如顺带进行的格式调整、轻微重命名或琐碎的注释清理，除非它们是本次更改的核心。
5. 起草提交消息
在写下消息的任何字符之前，先确定一条不可妥协的规则：整个提交消息都必须使用纯英文书写，包括标题、正文和每一行页脚。 这条规则优先于其他一切信号，包括用户调用此技能时使用的语言、之前提交所用的语言、分支名称、问题标题、代码注释、周边文档，以及推断出的区域设置或团队惯例。输出中任何位置都不得出现中文、日文、韩文或其他非英文字符，也不得混用语言。代码库中已有的非英文专有名词、标识符、文件路径和 API 名称应保持原样，但其周围的所有文字仍必须使用英文。如果用户请求与此规则冲突，应拒绝切换语言，仍然使用英文。
确定这一约束后，依次起草标题、正文和页脚。
消息遵循以下规范结构——标题、可选正文、页脚，各区块之间空一行：
<type>[optional scope]: <subject>
<optional single paragraph>
- <top-level bullet>
- <nested bullet>
- <nested bullet>
- <deeper nesting, depth is unrestricted>
- <top-level bullet>
- <nested bullet>
- <nested bullet>
<footer>
type 和 subject 为必填项；scope 为可选项。页脚为必填项，除非用户明确要求省略。正文为可选项，最多包含一个散文段落和一个连续列表，两者均可单独省略。
不要强行换行。每个逻辑行（主题行、段落、每条项目符号、每行页脚）都占一行；需要多长就写多长——渲染器会重新排版，预先换行只会造成碎片。
正文不得包含第二个段落，也不得包含第二组“段落加列表”。如果你想写第二组，其实你要表达的是多个独立要点——应将它们合并为一个（可嵌套的）列表。以下两种结构均不可接受：
<paragraph>
<paragraph>
<paragraph>
- <item>
<paragraph>
- <item>
所有项目符号都使用 -，嵌套层级每层缩进两个空格；嵌套深度不受限制。
5a. 起草标题
使用以下模式：
<type>[optional scope]: <subject>
只有在能提升可搜索性或审查价值时，才选择可选的 scope。合适的范围包括稳定的模块名称、子系统或有意义的路径。如果范围含糊、过于宽泛或多余，则省略。
让主题行的信息密度尽可能高：
- 主题行首字母大写。
- 使用祈使语气。
- 主题行末尾不要加句号。
- 优先使用一个明确的操作，而不是含糊笼统的表述。
- 不要试图在标题中列出所有附带改动。
5b. 起草正文
只有在能提升清晰度时才添加正文。
需要正文时：
- 用一个空行将正文与标题隔开。
- 说明做了哪些改动以及其重要性。
- 将未能写进标题的重要次要改动补充到正文中。
- 描述多个不同要点时使用
-项目符号。 - 正文应聚焦于对审查者有价值的信息，而不是逐行复述差异。
5c. 起草页脚
此步骤最多可添加两类 Co-Authored-By 页脚：用户提供的人类共同作者，以及 Agent 自身的共同作者行。人类共同作者部分为可选项，是否添加取决于用户输入；Agent 共同作者部分默认必填，只有用户明确要求时才省略。始终将人类共同作者行放在 Agent 行之前，以确保署名顺序优先体现用户。
5c-i. 添加人类共同作者（可选）
只有在确有需要时才添加此部分，即用户提供或暗示了一位或多位人类共同作者。如果没有相关共同作者，则完全跳过本小节。
对于共同作者：
- 如果用户明确提供共同作者信息，每人添加一行
Co-Authored-By: Name <email>页脚。 - 如果用户提供的共同作者信息不完整，应先尝试通过 Git 历史补全缺失字段，再提出追问。优先使用
git log --format='%an <%ae>' --all和附近的历史记录，不要猜测。 - 如果仍无法可靠确认姓名或邮箱，应向用户询问缺失信息，不要编造。
5c-ii. 添加 Agent 联合作者（默认必须添加）
始终追加且仅追加一行 Agent 联合作者信息。仅当用户明确要求不添加时才跳过。
格式必须严格如下：Co-Authored-By: <Agent Name> <Model Name> <email>。
<email> 必须属于 Agent 供应商，而非底层模型供应商。根据 Agent 品牌确定邮箱：Claude 系列 Agent 使用 [email protected]，Codex 使用 [email protected]，TraeCli 使用 [email protected]，依此类推。当 Agent 使用第三方模型或路由模型时（例如 ByteDance Agent 中由 OpenRouter 提供服务的模型），邮箱仍应对应托管该 Agent 的供应商，而非模型提供商。如果不知道 Agent 供应商的 noreply 域名，请询问用户，不要自行编造。
正确的 Agent 页脚格式示例：
Co-Authored-By: Claude Opus 4.6 <[email protected]> # baseline: agent and model from the same vendor
Co-Authored-By: Codex GPT-5 <[email protected]> # different agent vendor shifts the email domain accordingly
Co-Authored-By: Claude Code Deepseek Reasoner <[email protected]> # mixed vendors: model name reflects the actual runtime model, email tracks the agent vendor — never coerce the model name to match the agent's brand
错误格式示例——请勿使用：
Co-Authored-By: Claude <[email protected]> # missing model name
Co-Authored-By: Claude Opus 4.6 ([email protected]) # parentheses instead of angle brackets
Co-Authored-By: claude-opus-4.6 <[email protected]> # slug instead of display name
Co-Authored-By: Opus 4.6 <[email protected]> # missing agent brand name
当人类联合作者和 Agent 联合作者同时出现时，先写人类联合作者：
Co-Authored-By: Jane Doe <[email protected]>
Co-Authored-By: Claude Opus 4.6 <[email protected]>
起草提交说明是此技能的一个子程序，不是最终输出。提交说明完全确定后，继续执行第 6 步以创建提交；不要在草拟完成后停下。如果草稿需要后续输入——例如联合作者信息尚未确定，或需要确认是否将自己添加为联合作者——请先解决这些问题，并仅在最终提交说明完成后创建提交。
6. 以非交互方式创建提交
使用起草好的提交说明原文作为提交消息。
安全地保留多行正文和页脚：
- 通过单引号 heredoc 传递消息，避免 shell 扩展并防止清理失败：
git commit -m "$(cat <<'EOF'\n<message>\nEOF\n)" EOF两侧的单引号会禁用 heredoc 内的变量和命令替换。- 不要启动用户的编辑器。
- 除非提交前必须进行纯机械性更正，否则不要重写提交说明。
7. 明确处理失败情况
出现以下任一情况时，请停止，不要自行变通：
- 没有值得提交的暂存差异
- 在
HEAD模式下，git add -A未能完整捕获工作树 - 无法确定最终页脚信息
git commit因钩子、冲突或仓库状态而失败
报告具体阻碍以及导致问题的命令或状态。
8. 报告结果
成功提交后，准确展示以下两项：
- 创建提交所用的模式——仅暂存模式或
HEAD模式（如果无参数调用自动切换到HEAD模式，请简要注明） - 完整的
git log -1输出，以便同时查看哈希、主题、正文和页脚
提交本身是主要产物。