技能使用指南

commit（Git提交与PR合并工作流）Skill 是什么？如何下载？

commit（Git提交与PR合并工作流）Skill 把检查状态、建分支、精准暂存、AI写提交信息、创建PR、合并删分支到汇报结果串成一条自动流程，内置禁用全量暂存、排除敏感文件等安全约束。本文详解安装步骤、使用方法、竞品对比与典型场景，帮你一次跑通标准PR循环。

Git提交与PR合并工作流Skillcommit
8 个章节 约 14 分钟阅读 AI 智能生成

Git提交与PR合并工作流Skill：把「暂存—提交—创建PR—合并清理」整条链路交给 AI 自动跑完

  • 一句话定位：这是一个把标准 Git 协作闭环固化成 7 个可执行步骤的 AI 技能，从看状态、开分支、精准暂存，到写提交信息、推远端、建 PR、合并删分支，一次调用全流程完成。
  • 核心差异：它不只是"帮你写一句 commit message"，而是把分支策略、暂存范围、PR 模板、合并方式这些容易出错的规范动作全部编码进流程。
  • 安全设计：明确禁止 git add -A，要求逐文件暂存，并强制排除 settings.local.json 等含密钥的文件，从源头降低误提交风险。
  • 调用极简：只接受一个可选参数——提交消息；不传时由 AI 分析暂存差异自动撰写，且强调解释"为什么改"而非"改了什么"。
  • 适用人群：日常需要频繁走 PR 流程的个人开发者、小团队协作者，以及想让 AI 编码工具真正跑通"最后一公里"的工程团队。

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

技能中文名：Git提交与PR合并工作流Skill 技能英文名：commit 技能ID：13628

它要解决的问题很具体：大多数开发者不缺写代码的能力，缺的是收尾环节的确定性。改完代码之后，git status 看一眼、git add 挑文件、憋一句 commit message、创建分支、推上去、在网页端建 PR、填摘要和测试计划、点合并、切回主分支、删掉远端分支——这套动作本身没有技术难度，但重复、琐碎、容易漏步骤。尤其是当你同时开着多个 AI 编码会话时，"忘记开新分支直接提交到主分支"和"顺手 git add -A 把本地配置文件一起提交"是高频事故。

这个技能把这些动作变成一个有固定顺序、有明确约束的执行清单：它只允许调用 Bash、Read、Glob 三类工具，并且被设置为不自动触发（需要你显式调用），从根本上保证"提交与合并"这种高风险操作不会在你不知情时发生。

安装思路与步骤：

  1. 确认前置条件：这是一个基于命令行的 Git/GitHub 协作技能，需要本地已安装 Git 并初始化仓库、已配置远端仓库，以及已安装并登录 GitHub CLI（gh），因为创建 PR 与合并依赖 gh pr create、gh pr merge 命令；同时需要在支持 AI 技能（Skill）机制的客户端环境中使用。具体版本要求与依赖清单以官方说明为准。
  2. 获取技能：在技能市场或技能库中按技能ID 13628 或英文名 commit 检索并添加；也可按官方文档指引，将技能文件放入本地技能目录。具体安装命令、目录路径以官方说明为准。
  3. 完成授权与配置：确认客户端已允许该技能使用 Bash 等工具，并确保当前仓库的 SSH/Token 权限具备推送与创建 PR 的权限。
  4. 验证是否生效：在对话中显式调用该技能（可附带一个提交消息作为参数），观察它是否先执行 git status、git diff --stat、git log --oneline -5 做状态检查，再询问或创建分支。若它按这个顺序动作，说明技能已加载成功。

这种"一键安装 + 固定流程"的思路，本质上把团队里资深工程师的 Git 习惯，变成了任何成员都能直接复用的标准动作，而不需要再写一份 Wiki 让人背诵。

该技能的主要功能和特点

  • 全流程闭环，而非单点辅助：覆盖检查状态 → 创建分支 → 暂存文件 → 提交 → 推送并建 PR → 合并并清理 → 汇报结果，共 7 个环节，缺一不可，避免"提交完就忘了推送"这类断裂。
  • 强制新分支策略：技能明确规定"总是创建新分支，切勿直接提交到主分支"，分支名要求简短且具描述性，天然规避了污染主分支的风险。
  • 精准暂存，拒绝一把梭：要求 git add <文件1> <文件2> ... 逐文件添加，明确写出"切勿使用 git add -A"，并点名排除 .claude/settings.local.json 及任何包含秘密的文件。
  • 提交消息的"为什么"导向：若你通过 $ARGUMENTS 传入消息，则严格按你给的原样使用；若不传，则由 AI 分析暂存差异后自行撰写，并强调要解释为什么改，而不仅仅是是什么。
  • 标准化 PR 模板：自动生成含「摘要」（1–3 个要点）与「测试计划」（清单）两段结构的 PR 描述，团队评审时信息完整度一致。
  • 合并方式统一：默认使用 --merge 而非 --squash 或 --rebase，除非另行要求，保证提交历史策略在团队内不被个人偏好打散。
  • 合并后自动清理：合并同时删除远端分支，并切回主分支执行 git pull，把"本地还停在旧分支"这种隐性混乱一并解决。
  • 只读 + 执行的最小工具面：仅开放 Bash、Read、Glob，且不自动触发调用，权限边界清晰。

和普通"AI 生成 commit message"工具相比，它强在把规范写死在流程里：普通工具帮你写一句话，它帮你不犯错。

如何使用该技能？

第 1 步：显式调用技能 在完成代码修改后，在对话中直接调用该技能。参数是可选的提交消息，例如：

  • 不传参数：/commit——由 AI 分析差异后自动撰写提交消息。
  • 传参数：/commit 修复登录接口在 token 过期时未返回 401 的问题——技能会原样使用这条消息，不再改写。

第 2 步：让技能先做状态体检 它会依次执行：

git status
git diff --stat
git log --oneline -5

这一步的产出是给你确认"到底改了哪些文件、最近 5 条提交长什么样"。请务必阅读输出，确认没有意外文件混入。

第 3 步：确认分支 技能会基于当前状态创建分支：

git checkout -b <简短描述性分支名称>

例如 fix/login-token-401。此时你可以检查分支名是否符合团队命名规范。

第 4 步：逐文件暂存 技能会添加具体文件：

git add src/auth/login.ts src/auth/types.ts

并主动跳过 settings.local.json 与任何看起来像密钥的文件。如果你想额外排除某个文件，在这一步直接告知即可。

第 5 步：生成提交 按你传入的消息提交；未传入则由 AI 撰写：

git commit -m "$(cat <<'EOF'
<提交消息在此>
EOF
)"

第 6 步：推送并创建 PR 技能会执行 git push -u origin <分支名称>，随后用 gh pr create 生成带摘要与测试计划的 PR 描述，描述末尾带有由 Claude Code 生成的标注。

第 7 步：合并与清理 默认执行：

gh pr merge <PR编号> --merge --delete-branch
git checkout main
git pull

第 8 步：读取报告 技能最终会输出 PR 的 URL 以及本次合并的内容摘要。把这段信息贴到团队频道，协作流程即闭环。

输出预期：一次调用后，你应当拿到——一个新分支、一次带说明的提交、一个含摘要与测试计划的 PR、一次 --merge 合并、一次分支删除、一次主分支同步，以及一份可转发的文字报告。

同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
本技能（commit） 提交—PR—合并全流程自动化技能 状态检查、建分支、精准暂存、AI 写提交、建 PR、合并删分支、汇报 需已装 Git 与 GitHub CLI、已登录并授权；在支持技能机制的客户端中加载，门槛中等 个人或小团队的标准 PR 循环、AI 编码后的收尾 优势：流程完整、内置安全约束（禁 add -A、排除敏感文件）、合并策略统一；不足：强依赖 gh 与 GitHub 生态，非 GitHub 平台需另作适配
GitHub CLI 手动操作 命令行工具集 git 与 gh 全部原子命令 门槛中，需熟记命令与参数 所有 Git 工作流 优势：完全可控、无依赖；不足：步骤全靠人记，容易漏掉删分支、切回主分支、写 PR 模板
通用 AI 编程助手（对话式） 通用编码助理 生成提交信息、解释差异、回答问题 门槛低，通常已集成在编辑器内 只想要一句 commit message 优势：上手快；不足：默认不负责建分支与合并，规范约束弱，容易"顺手 add -A"
Git 图形化客户端 可视化仓库管理 暂存、提交、推送、发起 PR 的图形操作 门槛低，需安装桌面软件 偏好可视化操作的开发者 优势：所见即所得，冲突处理直观；不足：PR 描述与测试计划多为手填，"为什么改"的表达质量依赖个人

选型建议：如果你已经习惯命令行且在意流程一致性，本技能最贴合；如果你更依赖可视化或使用非 GitHub 平台，图形客户端或手动 CLI 更稳妥。

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

场景一：AI 编码结束后的"最后一公里" 角色：独立开发者。痛点：让 AI 改完代码后，经常忘记开新分支，或者顺手把 .env、本地配置文件一起提交。使用方式：改完直接调用技能并附一句提交消息。实际体验：上手几乎零成本，因为参数只有一个且可选；最有价值的是它会主动打印状态检查结果，你在合并前有机会发现误暂存；注意点是首次使用要确认 gh 已登录，否则会在建 PR 那一步失败。

场景二：小团队的规范化 PR 流程 角色：3–5 人小团队的技术负责人。痛点：每个人 PR 描述格式都不一样，有人只写一句话，评审时看不出改动动机与测试情况。使用方式：要求成员统一走该技能，PR 自动带上「摘要 + 测试计划」两段。实际体验：信息完整度提升明显，评审时能直接看到"为什么改"；注意点是摘要内容由 AI 根据差异生成，复杂改动仍建议人工补两句背景。

场景三：多任务并行时的分支卫生 角色：同时推进多个需求的开发者。痛点：来回切分支后本地状态混乱，合并完还停留在旧分支，main 也忘记拉取。使用方式：每个需求结束调用一次技能，让它完成"合并 + 删分支 + 切回主分支 + pull"。实际体验：这是最省心的一环，把"收尾动作"彻底外包；注意点是它默认用 --merge，若团队规范是 squash，需要明确要求。

场景四：高频小改动仓库 角色：维护文档站或工具库的开发者。痛点：每天十几次小提交，逐条手写提交信息很枯燥。使用方式：不传参数，让 AI 自动分析差异撰写。实际体验：AI 写出的消息通常能说清动机，比"update files"强很多；注意点是不传参时生成质量取决于差异清晰度，一次改太多无关文件会稀释信息量，建议小步提交。

整体上手难度偏低，属于"调用一次就能感受到收益"的类型；效果好坏的关键在于你是否认真看待它打印的状态检查输出。

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

效率层面：原本需要 8–10 次命令交互、跨越终端与浏览器两端的收尾流程，被压缩为一次调用加一次确认。按每天 3 次 PR 循环、每次节省 5–8 分钟估算，一周可回收 1 小时以上；对高频小步提交的仓库，收益更明显。

风险层面：把"禁止 git add -A"“排除敏感文件”“禁止直提主分支”"合并后删分支并同步主分支"这些过去写在文档里靠自觉的规范，变成流程中的硬约束，直接减少密钥泄漏与主分支污染两类高代价事故。

协作层面：统一的 PR 摘要与测试计划结构、统一的 --merge 合并策略，让提交历史与评审信息保持一致，新人加入时不需要背诵额外规范，门槛从"记住一套规矩"降为"调用一个技能"。

长期价值：团队真正沉淀下来的不是某个人的 Git 技巧，而是一条可被 AI 复用、可被审查、可被修改的流程资产——想调整合并方式或 PR 模板，改流程即可，全团队同步生效。

常见问题 FAQ

Q1：怎么安装这个技能？需要准备什么？ 先确认本地已装 Git、已配置远端仓库，并安装登录 GitHub CLI（gh），因为创建 PR 与合并依赖它。随后在技能库中按技能ID 13628 或英文名 commit 添加，并按官方指引完成工具授权。具体安装命令与目录路径以官方说明为准。

Q2：它收费吗？ 技能本身不涉及额外计费，能否使用取决于你所用客户端的订阅策略与 GitHub 仓库权限；相关价格与授权范围以官方说明为准。

Q3：适合谁用？新手会不会把仓库搞乱？ 适合日常走 PR 流程的个人开发者与小团队。新手反而更适合——它强制新分支、逐文件暂存、合并后同步主分支，比手工敲命令更不容易出错。但请务必在它打印 git status 与 git diff --stat 结果时认真确认，这是最后一道人工闸门。

Q4：为什么默认用 --merge 而不是 --squash？能改吗？ 技能规定"使用 --merge（而非 --squash 或 --rebase），除非另有要求"，目的是让团队合并策略保持一致。若你的仓库规定 squash，在调用时明确说明即可覆盖默认行为。

Q5：和直接用 GitHub CLI 或图形客户端比，怎么选？ 只想要一句高质量提交信息、且流程自己完全掌握，用通用 AI 助手或图形客户端足够；希望"检查—分支—暂存—提交—PR—合并—汇报"一次跑完并自带安全约束，本技能更合适。若仓库托管在非 GitHub 平台，则优先考虑手动 CLI 或图形客户端。