skill-git-workflow（Git工作流技能）Skill 是什么？如何自动生成规范提交？

Git工作流技能Skill：让每一次任务状态变更都自动沉淀为一条规范提交

它是什么：一个专注于「提交纪律」的 AI 技能，在任务状态变更（研究完成、计划创建、实施完成）或工件创建后，自动生成范围精确、格式统一的 git 提交。
核心能力：内置任务操作与系统操作两套提交消息模板、三类提交范围规则、提交前安全检查，以及通过 [ci] 标记精确控制 CI 是否触发。
安全边界：工具权限被限定为 Bash(git:*)，并明确规定禁止 git push --force、无明确请求的 git reset --hard、git rebase -i 等高危操作。
容错设计：Git 失败不阻塞任务流程，任务状态照常保留，失败原因单独上报，避免"提交挂了导致整个工作流中断"。
适合谁用：使用 AI 编码代理进行多阶段任务开发、需要规范提交历史与可控 CI 成本的开发者与团队。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能中文名：Git工作流技能Skill 技能英文名：skill-git-workflow 技能ID：12894

这个技能要解决的问题非常具体：当你让 AI 代理连续完成「创建任务 → 完成研究 → 制定实施计划 → 分阶段实施 → 完成任务」这一长串动作时，代码仓库里往往会堆出一大坨混乱的改动——什么文件该进这次提交？提交信息写什么？这次改动要不要跑 CI？人工补提交既费时又容易漏，而让 AI 随意 git add . 又可能把 .env、凭证文件一起提交上去。

Git工作流技能Skill 把这件事变成了「有规则可依」的固定动作：它只在特定触发点激活（任务状态变更、工件创建、任务生命周期操作），按预设的消息模板生成提交，按范围规则只暂存该暂存的文件，并在提交前执行安全检查。

一键安装的思路与步骤

确认安装前提：需要一个支持 Skill（技能）机制的 AI 编程环境，并且当前项目已经是一个初始化好的 git 仓库（存在 .git 目录）。技能本身只需要 git 能力，详情中声明其允许工具为 Bash(git:*)，不依赖其他外部服务。
通过技能市场/技能库安装：在技能平台的技能页面检索技能名 skill-git-workflow 或技能ID 12894，点击安装/启用即可。具体的安装命令、入口路径与是否需要登录账号，以官方说明为准。
准备上下文文件（可选但推荐）：技能采用「上下文按需加载」的方式，通过 @ 引用读取规则文件：
- @.claude/context/core/standards/git-safety.md —— Git 安全规则与最佳实践
- @.claude/context/index.md —— 完整的上下文发现索引如果你的项目里已有这两个文件，技能就能读到团队自己的提交规范；没有的话技能仍可依靠内置模板工作。
验证是否生效：随便触发一次任务状态变更（例如让代理完成一次研究并记录结果），然后执行 git log -1 查看最新提交信息。若提交信息呈现 任务 {N}: 完成研究 这类结构化格式，并带有共同作者署名，说明技能已正常工作。也可以先用 git status 确认暂存范围是否符合预期。

该技能的主要功能和特点

触发式自动提交：不需要你手动说"帮我提交一下"。技能在任务状态变更（研究完成、计划完成、实施完成）、工件创建、任务生命周期操作发生时自动激活，把提交变成流程的一部分。
两套结构化消息模板：任务操作（创建任务、完成研究、创建实施计划、完成阶段、完成实施、修订计划）与系统操作（归档任务、错误修复、代码审查、状态同步）各有固定格式，提交历史天然可读、可检索、可统计。
三类提交范围规则：任务特定提交只包含 specs/TODO.md、specs/state.json、specs/{NNN}_{SLUG}/**；实施提交包含实际修改的源文件（如 Lean 任务的 Logos/**/*.lean、一般任务的 src/**/*）；阶段提交则严格限定为该阶段修改的文件 + 更新了阶段状态的计划文件。范围越精确，回滚与 review 的颗粒度就越细。
提交前安全检查：先 git status 核对暂存文件，再检查是否误暂存了敏感文件（.env、凭证），最后校验提交消息格式。三道关卡把"手滑提交密钥"的风险挡在门外。
CI 精确触发（[ci] 标记 / trigger_ci 参数）：默认情况下推送事件跳过 CI，只在需要时于提交消息追加 [ci]。技能还给出了明确的决策标准：改 Lean 文件、实施完成、改 CI 配置、更新 Mathlib 依赖、关键错误修复 → 触发；纯文档、研究/规划工件、普通任务管理 → 跳过。这直接降低了不必要的 CI 消耗。
结构化返回结果：每次执行返回 JSON，包含 status、summary、commit_hash、files_committed、message、ci_triggered，方便上层流程判断成功与否并做日志留痕。
非阻塞的容错行为：Git 失败时记录失败、继续任务、向用户报告，任务状态无论如何保留；提交前钩子失败时明确要求"修复问题并重试，不要用 --no-verify 绕过"，而不是粗暴跳过校验。

和普通 Git 工具/AI 提交助手的差别：普通工具关注"怎么把改动提交上去"，这个技能关注"在任务生命周期的哪个节点、用哪套模板、只提交哪些文件、要不要跑 CI"。它把团队约定固化成了可执行的规则，而不是依赖人每次记着。

如何使用该技能？

以下按"从零到跑通一次提交"的顺序说明。

第 1 步：让任务进入可触发状态 技能由任务状态变更驱动，所以先让代理进入任务流程，例如创建任务、完成研究、生成实施计划。这一步无需显式调用技能。

第 2 步：在状态变更点自动/显式触发 当一次研究或计划完成时，技能执行流程为：接收提交请求（操作类型、任务号、范围、消息模板）→ 暂存文件 → 格式化消息并提交 → 校验退出码 → 返回结果。你也可以显式指定参数，例如"以任务 12、范围 specs/、消息模板’完成研究’创建提交"。

第 3 步：确认暂存范围 任务提交的标准动作是 git add specs/，随后提交。若涉及源码实施，则按实施范围暂存对应源文件目录。

第 4 步：决定是否触发 CI 仅在必要场景（改 Lean 文件、实施完成、改 CI 配置、依赖更新、关键修复）将 trigger_ci 设为 true，技能会在消息末尾追加 [ci]。其余场景保持默认 false。

输入输出示例

假设完成了任务 12 的研究阶段，输出大致如下：

{
  "status": "completed",
  "summary": "创建提交: 任务 12: 完成研究",
  "commit_hash": "abc123",
  "files_committed": ["specs/TODO.md", "specs/state.json", "specs/012_user_login/"],
  "message": "任务 12: 完成研究

共同作者: Claude Opus 4.5 <noreply@anthropic.com>",
  "ci_triggered": false
}

若这次改动是完成实施且改了 Lean 文件，则应把 trigger_ci 置为 true，提交标题变为 任务 12: 完成实施 [ci]，返回中 ci_triggered: true。

无改动时：返回 status: "committed"、commit_hash: null、摘要为"无更改提交"，不会报错中断。 钩子失败时：返回 status: "failed" 并给出修复建议（修复后重试，不要 --no-verify）。 Git 命令本身出错时：返回 status: "failed" 并提示检查 git 状态后手动解决。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
Git工作流技能Skill（skill-git-workflow）	面向 AI 任务生命周期的自动提交技能	触发式提交、双套消息模板、三类范围规则、提交前安全检查、`[ci]` 精确触发、JSON 返回、非阻塞容错	支持 Skill 机制的环境 + git 仓库；上下文文件可选	AI 代理多阶段任务开发、需要规范提交历史与可控 CI 成本的项目	优势：与任务状态强绑定，范围与格式高度可控，安全规则明确；不足：仅专注提交环节，不含分支策略、code review 流程
纯手动 git 命令	最基础的版本控制操作	add / commit / push	零门槛	任何项目	优势：完全自由；不足：依赖人的纪律，AI 代理批量改动时容易漏提交、错暂存、提交信息混乱
通用 AI 编码助手的默认提交行为	助手"顺手"帮忙提交	大致按改动生成提交信息	随助手自带	轻量改动、单人项目	优势：无需额外配置；不足：缺范围约束，容易 `git add .` 带入敏感文件；无 CI 触发控制；无结构化返回
提交规范校验工具（如 commitlint 类工具）	校验提交消息是否符合规范	钩子校验消息格式	需要配置钩子与规则文件	团队统一提交信息格式	优势：强约束格式；不足：只校验不生成，仍需人或代理撰写消息；不解决"哪些文件该进这次提交"

可以这样理解差异：校验类工具是"事后把关"，手动命令是"全凭自觉"，通用助手的默认提交是"粗略代办"，而 Git工作流技能Skill 是"按任务生命周期编排的提交流水线"。

该技能的典型应用场景与实际体验情况

场景一：AI 代理长任务开发中的提交节点管理 角色：使用 AI 代理做多阶段功能开发的工程师。痛点：代理连续跑了两小时，中途改了十几个文件，最后一次性提交，历史完全看不出"研究—计划—实施"的演进过程，出问题无法精准回滚。使用方式：让技能在每个状态变更点自动提交，specs/ 与源码分开提交。实际体验：提交历史变成一条清晰的任务时间线，任务 12: 完成研究、任务 12: 创建实施计划、任务 12 阶段 2: 接口实现、任务 12: 完成实施 依次排列，回滚粒度明显变细。注意点是：需要保证任务号和范围参数被正确传入，否则消息前缀会缺失。

场景二：敏感文件防误提交 角色：团队里负责仓库安全的开发者。痛点：AI 代理执行 git add .，把本地 .env 或凭证文件一起提交上去。使用方式：依赖技能内置的提交前检查——先 git status 核对暂存文件，再检查是否暂存敏感文件，最后校验消息格式。实际体验：这是技能中最"无感但最值钱"的部分，日常不会感知，出事时会感谢它。注意点是：检查依赖于规则文件与实际文件命名，建议同时把敏感文件写进 .gitignore 做双保险。

场景三：CI 成本控制 角色：维护 Lean/Mathlib 相关项目的开发者。痛点：每次推送都跑 CI，纯文档改动也占几分钟构建时间，成本高、队列堵。使用方式：日常任务提交保持默认（不触发 CI），仅在改 .lean 文件、实施完成、改 .github/workflows/、更新 lakefile.lean/lake-manifest.json、关键错误修复时设 trigger_ci: true。实际体验：CI 运行次数显著下降，而需要验证的关键节点一个不漏。注意点是：拉取请求事件和手动 workflow_dispatch 本来就会跑 CI，[ci] 标记只在推送事件下起"开关"作用，别把两套机制搞混。

场景四：计划修订与状态同步的留痕 角色：需要长期维护 TODO.md 与 state.json 一致性的项目维护者。痛点：计划改了版本、任务归档了、错误修复计划创建了，这些"系统级动作"往往没人提交，状态文件和代码逐渐脱节。使用方式：使用系统操作的固定消息格式，例如 待办: 归档 {N} 已完成任务、错误: 创建 {N} 个错误的修复计划、审查: {范围} 代码审查、同步: 协调 TODO.md 和 state.json。实际体验：状态文件终于有了自己的提交历史，排查"什么时候变的"变得很容易。上手难度整体偏低，规则都是现成的；真正需要适应的是"提交时机从’我想提交’变成’流程该提交’"。

该技能能为用户带来的价值

把规范从"靠自觉"变成"靠机制"。提交信息的格式、暂存的范围、CI 的开关，这三件最容易在 AI 高速产出中被忽略的事，被前置成了技能的默认行为。团队不需要再写一份《提交规范》文档然后祈祷大家遵守。

降低 AI 代理操作 git 的风险。工具权限被限制在 Bash(git:*)，同时明确禁止 git push --force、无明确请求的 git reset --hard、git rebase -i，配合提交前的敏感文件检查，把"AI 把仓库搞坏"的概率压到很低。

提交历史变成可用的资产。当每条提交都带着任务号和动作语义，你获得的不只是日志，而是可以按任务维度统计进度、按阶段回溯改动、按动作筛选审查范围的能力。

CI 成本从"固定支出"变成"按需支出"。默认跳过 + [ci] 精确触发，让推送型 CI 只为真正需要验证的改动物化，对高频提交的项目是持续的节省。

流程韧性提升。Git 失败不阻塞任务，任务状态无论提交成败都保留，失败时明确要求修复而非绕过钩子——这意味着不会出现"因为一次提交报错，整条任务流水线重跑"的浪费。

长期看，这个技能的价值在于把"良好的仓库卫生习惯"变成了默认配置。新加入的代理、新的任务、新的成员，一开始就在规则之内。

常见问题 FAQ

Q1：这个技能怎么安装？需要额外付费吗？ A：在技能平台检索技能名 skill-git-workflow 或技能ID 12894，按平台指引安装/启用即可，前提是运行环境支持 Skill 机制且当前项目已是 git 仓库。关于是否需要付费、有没有付费档位差异，技能详情中未涉及，请以官方说明为准。

Q2：它会自动提交我所有的改动吗？会不会把不该提交的文件带上？ A：不会无差别提交。技能按三类范围规则暂存：任务提交只包含 specs/TODO.md、specs/state.json、对应任务目录；实施提交包含修改的源文件；阶段提交限定为该阶段改动。此外提交前会执行 git status 核对暂存内容并检查是否误暂存 .env、凭证等敏感文件。

Q3：为什么我的提交没有触发 CI？ A：这是默认行为。CI 在推送事件下默认跳过，需要在提交消息中追加 [ci] 标记（即把 trigger_ci 设为 true）才会触发。建议只在修改 Lean 文件、实施完成、CI 配置变更、依赖更新、关键错误修复等场景开启。另外，拉取请求事件和手动 workflow_dispatch 本身就会运行 CI，与标记无关。

Q4：提交失败了会中断我的任务吗？提交前钩子报错能用 --no-verify 跳过吗？ A：不会中断。技能采用非阻塞设计：记录失败、继续任务、向用户报告，任务状态无论如何都保留。但钩子失败时官方建议是修复问题后重试，不要使用 --no-verify 绕过校验。返回结果会带有 status: "failed" 和具体的 recovery 提示。

Q5：它和 commitlint 这类提交规范工具、或者 AI 助手自带的提交功能怎么选？ A：三者定位不同。校验类工具负责"事后把关消息格式"，AI 助手默认提交负责"粗略代办"，而 Git工作流技能Skill 负责"按任务生命周期编排提交"——决定何时提交、提交哪些文件、消息长什么样、要不要跑 CI。如果只是想统一消息格式，校验工具就够；如果你的痛点是 AI 长任务开发中提交混乱、范围失控、CI 成本高，那这个技能才是对症的。两者也可以叠加使用。