Visual Studio Code 内置 AI Commit 技能解读从 git diff 到符合仓库规范的提交信息【免费下载链接】vscodeVisual Studio Code项目地址: https://gitcode.com/GitHub_Trending/vscode6/vscode导读在 Visual Studio CodeCode OSS的智能代理Agent体系中commit是会话Sessions子系统中一组可执行产品工作流的内置技能Skill之一。它定义了 AI 代理在用户说出提交更改commit my changescheck in code时应遵循的完整操作规范先探测仓库既有的提交风格再仅针对暂存区内容生成一条 ≤72 字符、语义精确的提交信息并安全地执行git commit。阅读本文后你将理解该技能的触发条件、五步工作流中每条命令的设计意图、安全红线约束以及如何借助 VS Code 的定制机制覆写内置技能以适配团队规范。技能文件与它在代码库中的位置技能本体位于 commit/SKILL.md采用 Git 仓库中最常见的目录名/SKILL.md布局文件头frontmatter提供两个关键字段--- name: commit description: Commit staged or unstaged changes with an AI-generated commit message that matches the repositorys existing commit style. Use when the user asks to commit, commit changes, create a commit, save my work, or check in code. ---name与所在目录名一致description则是技能发现skill discovery的入口描述——它写明了该技能何时被唤醒用户请求 commit 相关操作时以及它的核心目标生成的提交信息必须匹配仓库既有的提交风格。从源码结构看这个技能处于一个更大的会话技能族谱中。同目录下还有一批功能互补的内置技能commit/SKILL.md —— 生成符合仓库风格的提交sync/SKILL.md —— 同步分支与上游 / 发布分支code-review/SKILL.md —— 对当前会话改动做代码评审create-pr、update-pr、merge 等 PR 生命周期技能fix-ci、troubleshoot、act-on-feedback 等治理类技能。这种编排并非巧合例如在 sync/SKILL.md 的工作流第一步中明确写着如果存在未提交更改先使用/commit技能提交它们再继续说明 commit 技能既可以被自然语言触发也可以被其他技能以斜杠命令/commit形式显式调用。src/vs/sessions/README.md 对该目录的定位做了一句话总结skills/*/SKILL.md是可执行的产品工作流executable product workflows它们不属于通用架构规范文档而是代理直接照做、可直接执行的规程。也就是说本文分析的这份文档本质上是一份给 AI 代理看的标准作业程序。技能文件格式与覆写override机制SKILL.md中紧跟在 frontmatter 后的一行注释揭示了内置技能的定制方式Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior.即这份内置技能可以在 VS Code 的定制界面中被复制成一份可编辑副本修改后保存即可覆写内置行为若删除副本则恢复为内置默认行为。把技能复制到哪里由用户/工作区决定。从同族技能 update-skills/SKILL.md 的说明可以看出技能的标准存放位置包括项目级.github/skills/{name}/SKILL.md随仓库提交与代理级.agents/skills/{name}/SKILL.md而SKILL.md文件中name字段必须与父目录名完全一致、description必须是一句话写清何时为何使用该技能这两点是技能被发现与正确调用的硬性约束。在代码实现层面Claude 代理端的技能扫描器 claudeAgentSkillScan.ts 将技能的磁盘布局描述为dir/SKILL.md frontmatter 中的name/description与本文这份文件的结构完全吻合扫描结果会通过pluginParsers.ts见 src/vs/platform/agentHost/common/agentPlugins/common/pluginParsers.ts解析供代理会话消费。可以推断commit 技能正是经由这样一条磁盘扫描 → frontmatter 解析 → 会话期技能列表的链路进入代理的能力清单的。工作流全景一条高质量提交的诞生技能正文定义了一个五步工作流。下面逐节还原并说明每一步命令为什么存在、返回结果如何影响后续行为。第 1 步探测仓库的提交规范代理要先回答一个前置问题这个仓库的提交信息长什么样命令如下# 最近 20 条仓库提交用于判断整体风格 git log --oneline -20 # 当前用户最近 10 条提交用于判断个人风格 git log --oneline --author$(git config user.name) -10输出会被用来判定仓库遵循的提交约定例如 Conventional Commitsfeat: ...、fix(scope): ...、Gitmoji✨ feat: ...、工单号前缀#1234 ...或自由格式。所有生成的消息必须遵循探测到的约定——这是本技能与其他随手写一条 commit message式实现最大的差异它把风格一致当作一等公民要求而不是事后可选项。值得注意的是第二条命令通过git config user.name动态取出当前提交者身份再过滤其个人历史。设计意图很明确当团队规范与个人习惯不同时常见于仓库由多人共同维护的场景以仓库整体风格为基准、以个人风格为参考来权衡措辞。第 2 步检查仓库状态决定暂存策略git status --short根据输出技能规定了三种分支情况没有任何改动工作树干净且无暂存内容→ 直接告知用户并停止不制造空提交存在已暂存staged改动→ 只提交这些改动绝不顺手git add任何未暂存文件仅有未暂存改动→ 执行git add -A暂存全部改动后再继续。第三条值得展开当用户只改了文件而未git add时代理需要git add -A把所有改动纳入暂存区。但注意该行为严格限定在只有未暂存改动这一前提——如果用户已经刻意选择性地暂存了部分文件技能会尊重这种选择避免破坏用户精心构造的原子提交边界。第 3 步读取完整 diff撰写提交信息拿到将要提交的内容的完整视图git diff --cached --stat git diff --cached--stat提供文件级摘要改了几行、涉及哪些文件完整 diff 则让代理理解改动实质。基于 diff 与第 1 步检测到的约定草拟提交信息需满足以下规则主题行 ≤ 72 字符概括改动遵循仓库约定可选正文仅当改动非平凡non-trivial时解释为什么要这样改而不是罗列文件名分支名或相关上下文中出现的issue / 工单号应当被引用聚焦改动意图intent避免逐文件记账式的流水账。这条规则直接把常见坏实践例如把git diff --name-only的输出拼进 message排除在外好的提交信息回答为什么而非改了哪些文件。第 4 步执行提交将上一步生成的内容组装成命令并执行git commit -m subject -m body使用两条独立的-m分别对应主题行与正文段避免 shell 转义问题也天然保证主题与正文在提交信息中被空行分隔。若没有正文则只保留第一条-m。第 5 步确认结果并处理 hook 副作用提交完成后做两个验证命令git status --short git log --oneline -1git status --short确认工作树已回归干净状态、提交确实落盘git log --oneline -1展示刚产生的那条提交。随后技能对可能发生的两类事后变化给出处理意见若pre-commit hooks阻断了提交或改动过文件要精确向用户总结发生了什么若 hooks 在提交尝试后重写了文件例如格式化器自动修正不要自动 amend而是告诉用户有哪些文件变了并询问是否要再次暂存并提交这些后续修改。这与绝不 amend的安全红线一脉相承hook 产生的连锁改动应当成为独立的新提交或经用户确认后再处理代理不得单方面改写历史。安全红线技能中最不可动摇的约束在任何操作之前技能先给出六条绝不级别Never的行为约束红线说明绝不 amend 既有提交除非用户明确要求否则不得改写已存在的提交绝不强推或推送未经用户明确批准不执行--force/--force-with-lease/ push绝不跳过 pre-commit hooks不使用--no-verify绝不跳过签名提交不使用--no-gpg-sign绝不 revert / reset / discard除非用户明确要求否则不丢弃任何用户改动有疑问就询问对暂存范围、仓库约定或 message 内容拿不准时问用户在红线之外还有两条风险识别要求检查是否混入明显不应提交的密钥secrets或生成产物发现可疑内容应询问用户这条安全护栏与同目录 code-review/SKILL.md 中安全与数据处理问题的审查维度互为呼应。对比同族的其他技能可以更好地理解这套红线体系的风格例如 sync/SKILL.md 同样规定未经批准绝不 force-push、绝不用--no-verify跳过 push hooks、rebase 时未经询问绝不改写或丢弃提交。可以推断这些技能共享同一套代理可读、只读操作可自主、改写历史的写操作必须征求用户同意的授权模型——这保证了代理在自动执行 git 操作时永远把用户的工作树安全放在第一位。实战复盘一次完整的技能调用把五个步骤串起来一次典型的commit技能调用过程如下用户在会话中输入帮我提交一下改动 →description中列出的触发词命中技能被唤醒代理执行git log --oneline -20发现仓库全部使用feat/fix/docs:前缀 → 判定为 Conventional Commitsgit status --short显示只有未暂存改动 → 代理执行git add -A读取git diff --cached --stat与git diff --cached识别出是一次 bug 修复且分支名形如fix/login-timeout-issue-4821生成信息主题行fix(login): handle session timeout on slow networks42 字符符合 ≤72 规则正文解释根因token 刷新竞态而非列出 6 个文件名并附上 issue 号Closes #4821以git commit -m ... -m ...提交若配置了 husky lint-staged 且提交前 hook 顺带格式化了两个文件代理会如实汇报hook 重写了文件 X、Y并询问是否需要再做一次提交——而不会擅自 amend。在仓库中继续深入查看技能原文commit/SKILL.md技能族定位与子系统约定src/vs/sessions/README.md与 commit 技能联动的相邻技能sync/SKILL.md未提交改动先走/commit、merge/SKILL.md、create-pr/SKILL.mdSKILL.md磁盘布局与 frontmatter 解析的扫描端实现claudeAgentSkillScan.ts、pluginParsers.ts技能的创建/维护方法论自定义与何时捕获学习标准update-skills/SKILL.md。小结这份内置 commit 技能的可贵之处在于它把写一条好提交信息这一看似简单、实则高度依赖上下文判断的任务拆解成了可被代理稳定执行的决策序列——探测约定 → 判定暂存策略 → 精读 diff → 按意图撰写 → 安全执行 → 验证结果。它同时是一个关于安全的范本能自主做的暂存、生成、提交放手做会改写历史的amend、force-push一律先问。对希望在 VS Code 代理体系内获得一致性 git 工作流、或想参考如何为 AI 代理编写可执行技能的开发者而言这份文档都是一份信息密度极高的一手规范。【免费下载链接】vscodeVisual Studio Code项目地址: https://gitcode.com/GitHub_Trending/vscode6/vscode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Visual Studio Code 内置 AI Commit 技能解读：从 git diff 到符合仓库规范的提交信息
Visual Studio Code 内置 AI Commit 技能解读从 git diff 到符合仓库规范的提交信息【免费下载链接】vscodeVisual Studio Code项目地址: https://gitcode.com/GitHub_Trending/vscode6/vscode导读在 Visual Studio CodeCode OSS的智能代理Agent体系中commit是会话Sessions子系统中一组可执行产品工作流的内置技能Skill之一。它定义了 AI 代理在用户说出提交更改commit my changescheck in code时应遵循的完整操作规范先探测仓库既有的提交风格再仅针对暂存区内容生成一条 ≤72 字符、语义精确的提交信息并安全地执行git commit。阅读本文后你将理解该技能的触发条件、五步工作流中每条命令的设计意图、安全红线约束以及如何借助 VS Code 的定制机制覆写内置技能以适配团队规范。技能文件与它在代码库中的位置技能本体位于 commit/SKILL.md采用 Git 仓库中最常见的目录名/SKILL.md布局文件头frontmatter提供两个关键字段--- name: commit description: Commit staged or unstaged changes with an AI-generated commit message that matches the repositorys existing commit style. Use when the user asks to commit, commit changes, create a commit, save my work, or check in code. ---name与所在目录名一致description则是技能发现skill discovery的入口描述——它写明了该技能何时被唤醒用户请求 commit 相关操作时以及它的核心目标生成的提交信息必须匹配仓库既有的提交风格。从源码结构看这个技能处于一个更大的会话技能族谱中。同目录下还有一批功能互补的内置技能commit/SKILL.md —— 生成符合仓库风格的提交sync/SKILL.md —— 同步分支与上游 / 发布分支code-review/SKILL.md —— 对当前会话改动做代码评审create-pr、update-pr、merge 等 PR 生命周期技能fix-ci、troubleshoot、act-on-feedback 等治理类技能。这种编排并非巧合例如在 sync/SKILL.md 的工作流第一步中明确写着如果存在未提交更改先使用/commit技能提交它们再继续说明 commit 技能既可以被自然语言触发也可以被其他技能以斜杠命令/commit形式显式调用。src/vs/sessions/README.md 对该目录的定位做了一句话总结skills/*/SKILL.md是可执行的产品工作流executable product workflows它们不属于通用架构规范文档而是代理直接照做、可直接执行的规程。也就是说本文分析的这份文档本质上是一份给 AI 代理看的标准作业程序。技能文件格式与覆写override机制SKILL.md中紧跟在 frontmatter 后的一行注释揭示了内置技能的定制方式Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior.即这份内置技能可以在 VS Code 的定制界面中被复制成一份可编辑副本修改后保存即可覆写内置行为若删除副本则恢复为内置默认行为。把技能复制到哪里由用户/工作区决定。从同族技能 update-skills/SKILL.md 的说明可以看出技能的标准存放位置包括项目级.github/skills/{name}/SKILL.md随仓库提交与代理级.agents/skills/{name}/SKILL.md而SKILL.md文件中name字段必须与父目录名完全一致、description必须是一句话写清何时为何使用该技能这两点是技能被发现与正确调用的硬性约束。在代码实现层面Claude 代理端的技能扫描器 claudeAgentSkillScan.ts 将技能的磁盘布局描述为dir/SKILL.md frontmatter 中的name/description与本文这份文件的结构完全吻合扫描结果会通过pluginParsers.ts见 src/vs/platform/agentHost/common/agentPlugins/common/pluginParsers.ts解析供代理会话消费。可以推断commit 技能正是经由这样一条磁盘扫描 → frontmatter 解析 → 会话期技能列表的链路进入代理的能力清单的。工作流全景一条高质量提交的诞生技能正文定义了一个五步工作流。下面逐节还原并说明每一步命令为什么存在、返回结果如何影响后续行为。第 1 步探测仓库的提交规范代理要先回答一个前置问题这个仓库的提交信息长什么样命令如下# 最近 20 条仓库提交用于判断整体风格 git log --oneline -20 # 当前用户最近 10 条提交用于判断个人风格 git log --oneline --author$(git config user.name) -10输出会被用来判定仓库遵循的提交约定例如 Conventional Commitsfeat: ...、fix(scope): ...、Gitmoji✨ feat: ...、工单号前缀#1234 ...或自由格式。所有生成的消息必须遵循探测到的约定——这是本技能与其他随手写一条 commit message式实现最大的差异它把风格一致当作一等公民要求而不是事后可选项。值得注意的是第二条命令通过git config user.name动态取出当前提交者身份再过滤其个人历史。设计意图很明确当团队规范与个人习惯不同时常见于仓库由多人共同维护的场景以仓库整体风格为基准、以个人风格为参考来权衡措辞。第 2 步检查仓库状态决定暂存策略git status --short根据输出技能规定了三种分支情况没有任何改动工作树干净且无暂存内容→ 直接告知用户并停止不制造空提交存在已暂存staged改动→ 只提交这些改动绝不顺手git add任何未暂存文件仅有未暂存改动→ 执行git add -A暂存全部改动后再继续。第三条值得展开当用户只改了文件而未git add时代理需要git add -A把所有改动纳入暂存区。但注意该行为严格限定在只有未暂存改动这一前提——如果用户已经刻意选择性地暂存了部分文件技能会尊重这种选择避免破坏用户精心构造的原子提交边界。第 3 步读取完整 diff撰写提交信息拿到将要提交的内容的完整视图git diff --cached --stat git diff --cached--stat提供文件级摘要改了几行、涉及哪些文件完整 diff 则让代理理解改动实质。基于 diff 与第 1 步检测到的约定草拟提交信息需满足以下规则主题行 ≤ 72 字符概括改动遵循仓库约定可选正文仅当改动非平凡non-trivial时解释为什么要这样改而不是罗列文件名分支名或相关上下文中出现的issue / 工单号应当被引用聚焦改动意图intent避免逐文件记账式的流水账。这条规则直接把常见坏实践例如把git diff --name-only的输出拼进 message排除在外好的提交信息回答为什么而非改了哪些文件。第 4 步执行提交将上一步生成的内容组装成命令并执行git commit -m subject -m body使用两条独立的-m分别对应主题行与正文段避免 shell 转义问题也天然保证主题与正文在提交信息中被空行分隔。若没有正文则只保留第一条-m。第 5 步确认结果并处理 hook 副作用提交完成后做两个验证命令git status --short git log --oneline -1git status --short确认工作树已回归干净状态、提交确实落盘git log --oneline -1展示刚产生的那条提交。随后技能对可能发生的两类事后变化给出处理意见若pre-commit hooks阻断了提交或改动过文件要精确向用户总结发生了什么若 hooks 在提交尝试后重写了文件例如格式化器自动修正不要自动 amend而是告诉用户有哪些文件变了并询问是否要再次暂存并提交这些后续修改。这与绝不 amend的安全红线一脉相承hook 产生的连锁改动应当成为独立的新提交或经用户确认后再处理代理不得单方面改写历史。安全红线技能中最不可动摇的约束在任何操作之前技能先给出六条绝不级别Never的行为约束红线说明绝不 amend 既有提交除非用户明确要求否则不得改写已存在的提交绝不强推或推送未经用户明确批准不执行--force/--force-with-lease/ push绝不跳过 pre-commit hooks不使用--no-verify绝不跳过签名提交不使用--no-gpg-sign绝不 revert / reset / discard除非用户明确要求否则不丢弃任何用户改动有疑问就询问对暂存范围、仓库约定或 message 内容拿不准时问用户在红线之外还有两条风险识别要求检查是否混入明显不应提交的密钥secrets或生成产物发现可疑内容应询问用户这条安全护栏与同目录 code-review/SKILL.md 中安全与数据处理问题的审查维度互为呼应。对比同族的其他技能可以更好地理解这套红线体系的风格例如 sync/SKILL.md 同样规定未经批准绝不 force-push、绝不用--no-verify跳过 push hooks、rebase 时未经询问绝不改写或丢弃提交。可以推断这些技能共享同一套代理可读、只读操作可自主、改写历史的写操作必须征求用户同意的授权模型——这保证了代理在自动执行 git 操作时永远把用户的工作树安全放在第一位。实战复盘一次完整的技能调用把五个步骤串起来一次典型的commit技能调用过程如下用户在会话中输入帮我提交一下改动 →description中列出的触发词命中技能被唤醒代理执行git log --oneline -20发现仓库全部使用feat/fix/docs:前缀 → 判定为 Conventional Commitsgit status --short显示只有未暂存改动 → 代理执行git add -A读取git diff --cached --stat与git diff --cached识别出是一次 bug 修复且分支名形如fix/login-timeout-issue-4821生成信息主题行fix(login): handle session timeout on slow networks42 字符符合 ≤72 规则正文解释根因token 刷新竞态而非列出 6 个文件名并附上 issue 号Closes #4821以git commit -m ... -m ...提交若配置了 husky lint-staged 且提交前 hook 顺带格式化了两个文件代理会如实汇报hook 重写了文件 X、Y并询问是否需要再做一次提交——而不会擅自 amend。在仓库中继续深入查看技能原文commit/SKILL.md技能族定位与子系统约定src/vs/sessions/README.md与 commit 技能联动的相邻技能sync/SKILL.md未提交改动先走/commit、merge/SKILL.md、create-pr/SKILL.mdSKILL.md磁盘布局与 frontmatter 解析的扫描端实现claudeAgentSkillScan.ts、pluginParsers.ts技能的创建/维护方法论自定义与何时捕获学习标准update-skills/SKILL.md。小结这份内置 commit 技能的可贵之处在于它把写一条好提交信息这一看似简单、实则高度依赖上下文判断的任务拆解成了可被代理稳定执行的决策序列——探测约定 → 判定暂存策略 → 精读 diff → 按意图撰写 → 安全执行 → 验证结果。它同时是一个关于安全的范本能自主做的暂存、生成、提交放手做会改写历史的amend、force-push一律先问。对希望在 VS Code 代理体系内获得一致性 git 工作流、或想参考如何为 AI 代理编写可执行技能的开发者而言这份文档都是一份信息密度极高的一手规范。【免费下载链接】vscodeVisual Studio Code项目地址: https://gitcode.com/GitHub_Trending/vscode6/vscode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
