Git 工作流三件套

它替你干掉什么：九个能装的，先给表

装法（都是原样能敲的）

# 1) 官方内置，零安装（据 Claude Code · Common workflows，2026-09）
create a pr                      # 文档里给的原话，直接说这一句
claude --from-pr 1234            # 回到当初开这个 PR 的那一场会话
claude --worktree feature-auth   # 另开一场并行，互不踩

# 2) superpowers（含 finishing-a-development-branch / using-git-worktrees）
/plugin install superpowers@claude-plugins-official

# 3) aidankinzett 那个 PR 审查件
/plugin marketplace add aidankinzett/claude-git-pr-skill

# 4) davila7 的 CLI，交互式挑组件（agent / command / hook / mcp / skill）
npx claude-code-templates@latest
# 最土也最通用的办法：把 SKILL.md 所在的文件夹整个拷进 ~/.claude/skills/

第一条立刻能跑的用法，一个字节都不用装——官方文档里就有这条管道：

git log --oneline -20 | claude -p "summarize these recent commits"

把后半句换成「按 feature / fix / breaking 分组，写成给用户看的发版说明」，你就已经有了一个 changelog 生成器。先跑这一条，再决定要不要装那个 skill。

机制：diff 是唯一输入，这决定了它的天花板

diff 能做对的部分

git-commit-helper（SKILL.md）的做法很典型：读 git diff --staged 与 git status，产出 <type>(<scope>): <description>，type 限定在 feat / fix / docs / style / refactor / test / chore，摘要 50 字符内、祈使句、句尾不加标点，并提示用 git add -p 把混在一起的改动拆开。这几件事 diff 里全有答案：类型看改了什么文件，scope 看目录，该不该拆看改动有几簇。所以这一段它做得比人稳——人会偷懒写「update」。

diff 里没有的那一半

同一份 SKILL.md 又要求「body 解释 reasoning，不只是动作」。而 reasoning 不在 diff 里。模型只能从代码反推动机，反推出来的通常是把 what 换个说法再讲一遍——这就是这类 skill 唯一真实的失败模式。

链条越往下游，信息丢得越多

changelog 类的输入不是 diff，是 commit message。changelog-generator（Composio 与 davila7 都收了同一份）做六件事：按时间段或 tag 区间扫历史、分类、把开发者用词改写成用户用词、排版、过滤掉重构和测试这类内部提交、再套品牌口径。它的上限被你的提交质量死死卡住。

这就是 Conventional Commits 真正值钱的地方：feat: / fix: / BREAKING CHANGE 不是格式洁癖，是你在提交那一刻留给下游机器的结构化元数据。留了，changelog 和版本号就能算出来；没留，下游只能靠模型猜。

真实用法与边界：约定用样例编码，危险动作用脚本钉死

把团队约定编进去：贴样例，别写条款

默认的 conventional commits 谁都能背，但你们仓库真正的口径是背不出来的：scope 该写包名还是模块名、多大的改动才算 feat、要不要挂 issue 号。最省事的做法是打开你们最近二十条大家都认可的提交，挑三到五条整段贴进 SKILL.md 当样例——三对真实的「diff 长这样 → message 这么写」比十条规则管用得多（这条配方 Skill 18 会单独拆）。放哪：团队共享就放进仓库的 .claude/skills/ 跟着代码走，个人偏好放 ~/.claude/skills/。

PR 那一摊：好 skill 都明写自己不管什么

• github-pr-review（aidankinzett/claude-git-pr-skill，MIT）：用 gh 的 pending review 把多条评论攒成草稿，最后由你一次提交——闸门在人手上。
• gh-address-comments（SKILL.md）：先查 gh auth status，再拉回 PR 上所有评论与 review 线程，编号列给你挑，你选哪几条它改哪几条。
• gh-fix-ci（SKILL.md）：gh pr checks → gh run view --log 把失败日志捞出来，先出修复计划、等你批准再动手；而且它的 description 里就写明——外部 check（比如 Buildkite）只报链接、标为 out of scope。这种「明写自己不管什么」是好 skill 的标志，比多管一摊值钱。

不可逆的一步，交回给人

superpowers 的 finishing-a-development-branch（SKILL.md）是这一类里最该抄的一个。它先跑全量测试，测试没过就停，连菜单都不给你看；然后判断是普通仓库还是 worktree、确认基线分支（拿不准就问「这条分支是从 X 分出来的吧？」），最后给出恰好三条的菜单：本地合回去 / 推上去开 PR / 就这么放着我自己来——然后等人选。SKILL.md 把理由写死了：集成决策属于人。删除更狠，要你手打「discard」这个词才执行。

另一条路是把动作钉进脚本。git-pushing（SKILL.md）要求一律走它自带的 scripts/smart_commit.sh，原话是「ALWAYS use the script — do NOT use manual git commands」。确定性的步骤写进脚本，模型只负责填那句 message，这是所有涉及 push 的 skill 都该照抄的结构。

代价与替代品：什么时候一条 hook 比 skill 更合适

为什么钩子更可靠：skill 是建议，钩子是拒绝

skill 注入的是指令，模型可以不听、可以没被触发、可以这次听下次不听。钩子是代码，它在事件上无条件执行。Claude Code 的 hooks 文档把这层关系说得很清楚：「钩子可以拒绝这次调用，但它保持沉默并不等于批准。」—— PreToolUse 上挂一条模式匹配拦住 git push --force，比在 SKILL.md 里写十遍「不要强推」牢靠得多。

三件事，该让确定性工具做

1. 格式合规 → commitlint（MIT）。npm install --save-dev @commitlint/cli，再按官方 local-setup 指南挂进 husky 的 commit-msg 钩子。替你干掉：靠 review 抓格式。什么时候别装：团队还没定下规范，先定规范再上工具。
2. changelog 与版本号 → git-cliff（Apache-2.0 / MIT 双授权，cargo install git-cliff，也有 npm / PyPI / Docker 分发）或 release-please（Apache-2.0，官方推荐用 release-please-action）。后者维护一个随提交持续更新的 release PR，你合并它就自动打 tag、发 release。什么时候别装：你的提交历史根本不守 conventional commits——这两个都从提交里解析，垃圾进垃圾出。
3. 提交前的固定检查 → 一条 pre-commit 钩子。davila7 的 CLI 直接给了现成的：npx claude-code-templates@latest --hook git/pre-commit-validation --yes。

那 skill 还剩什么

剩下的恰好是钩子做不了的：commit body 里那句 why、把一坨混着的改动拆成几个提交、PR 描述里「reviewer 该测哪几条路径」。这三件都需要判断，也都没有客观判定器。这才是这一类 skill 真正的地盘，其余的都该往下沉。

三笔账

• 触发冲突：git-pushing 的 description 明写了它响应「push changes」「commit and push」「push this」这类说法。装得多，这些短语就成了抢答现场。
• 双写打架：既让 skill 写 CHANGELOG，又让 release-please 维护 release PR，两边会互相覆盖。一个仓库只留一条 changelog 生产线。
• 信任错位：skill 写的 message 你不看就提交，等于把仓库历史的质量交给了一个看不见 why 的读者。