zhoujie
26ca0e6ab2
新增的技能把"生成规范 commit message"这套步骤固化下来(Conventional Commits 格式、提交前检查密钥/误提交的二进制文件),避免每次会话重新现编、 风格漂移。 CLAUDE.md 记录了这个技能库的目录结构、核心设计原则(反幻觉是硬约束、脚本 优先于临场编 API 调用、草稿区与交付物分离)、已知薄弱环节,以及已经和用户 确认的下一步计划(给检索脚本补测试和限流重试、新增引用一致性核查技能), 方便以后的会话不用重新推导这些上下文。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
78 lines
4.4 KiB
Markdown
78 lines
4.4 KiB
Markdown
---
|
|
name: git-commit
|
|
description: Generate a Conventional-Commits-style message from the repo's current staged/unstaged changes and create the commit. Use whenever the user explicitly asks to commit, save, or checkpoint their work ("提交一下", "commit这些改动", "帮我提交代码", "存一下进度", "commit this"). Never invoke this proactively — only when the user asks for a commit, not merely after finishing an edit. Does not cover pushing, PR creation, amending, or any other git operation.
|
|
---
|
|
|
|
# Git 提交(规范化 commit message)
|
|
|
|
## 为什么需要这个技能
|
|
|
|
"提交一下"这句话背后其实有一套容易被跳过的步骤:先看清楚这次改动到底涉及
|
|
哪些文件、有没有不该进版本库的东西(密钥、临时文件、误生成的二进制),再把
|
|
分散的改动归纳成一句准确说明"为什么改"而不是"改了什么"的话——好的commit
|
|
message省的是未来翻`git log`时重新读一遍diff的时间。这个技能把这套步骤和
|
|
一套固定的message格式(Conventional Commits)定下来,避免每次现编、风格漂移。
|
|
|
|
## 工作流程
|
|
|
|
### 第一步:摸清这次改动的全貌
|
|
|
|
并行执行:
|
|
- `git status`(不要加`-uall`,大仓库会有性能问题)
|
|
- `git diff` 看未暂存的改动,`git diff --cached` 看已暂存的改动
|
|
- `git log --oneline -10` 看最近的提交,判断这个仓库习惯的message风格(有的仓库不用Conventional Commits前缀,这时候跟随仓库现有风格优先于本技能默认的格式)
|
|
|
|
### 第二步:提交前检查——发现问题就先说清楚,不要直接提交
|
|
|
|
逐条过一遍将要暂存的文件,确认没有:
|
|
- 明显的密钥/凭据文件(`.env`、`credentials.json`、私钥等)——发现了就跳过并提醒用户,不要连带提交
|
|
- 不该进版本库的产物:打包导出的二进制(`.zip`/`.skill`等)、编辑器/系统临时文件、体积异常大的文件
|
|
- 用`git add -A`/`git add .`扫进来的、用户可能还不想提交的无关改动——按文件名显式`git add`,不要笼统全加
|
|
|
|
发现可疑内容,先列出来问用户怎么处理,不要自作主张排除或包含。
|
|
|
|
### 第三步:生成 commit message
|
|
|
|
采用 Conventional Commits 格式(除非第一步发现这个仓库明显用别的风格,这种情况下跟随仓库风格):
|
|
|
|
```
|
|
<type>(<scope>): <subject>
|
|
|
|
<body — 可选,只在"为什么"不是一眼能看出来的时候写>
|
|
```
|
|
|
|
- `type` 从改动的实际性质里选,不要凭感觉:`feat`(新功能)、`fix`(修bug)、
|
|
`refactor`(不改行为的重构)、`docs`(纯文档)、`test`(测试)、`chore`(构建/
|
|
依赖/杂项)、`style`(纯格式,不改逻辑)——一次提交只涉及一种性质就只写一个
|
|
type;如果改动明显跨性质(比如"顺手"把无关重构也塞进了这次提交),提醒用户
|
|
考虑拆成多个提交,而不是硬凑一个笼统的type。
|
|
- `scope` 可选,涉及单一模块/skill时加上(比如`literature-search-verify`、
|
|
`paper-writing-grounded`),改动横跨全仓库时省略。
|
|
- `subject` 祈使语气、不超过~70字符、不以句号结尾,说清楚这次改动做了什么,
|
|
但真正的价值在于讲清楚**为什么**要这么改——如果"为什么"不是从改动本身能
|
|
一眼看出来的(比如修了一个不明显的bug、调整了一个非默认行为),写进body里,
|
|
不要只重复diff里已经能看到的内容。
|
|
- 不要在message里提及和这次改动无关的历史背景或猜测性动机。
|
|
|
|
### 第四步:暂存并提交
|
|
|
|
- 按第二步筛选后的文件列表显式`git add <file1> <file2> ...`,不要`-A`/`.`
|
|
- 用 heredoc 传message,保证多行格式正确:
|
|
```bash
|
|
git commit -m "$(cat <<'EOF'
|
|
<type>(<scope>): <subject>
|
|
|
|
<body>
|
|
EOF
|
|
)"
|
|
```
|
|
- 提交后跑一次`git status`确认工作区状态符合预期
|
|
|
|
### 第五步:红线
|
|
|
|
- 只在用户明确要求提交时才创建commit,不要在完成一次编辑后主动提交
|
|
- 不新建commit时优先于`--amend`——只有用户明确要求"修改上一个commit"才用amend,而且如果上一次是因为pre-commit hook失败而"没有真正提交成功",绝不能用`--amend`(那样会改到更早的一个commit)
|
|
- 不加`--no-verify`/`--no-gpg-sign`跳过hook或签名,除非用户明确要求;hook失败时先定位问题、修复后重新`git add`再建一个新commit
|
|
- 不主动`git push`,除非用户在这次请求里明确说了要推送
|
|
- 不做`reset --hard`/`checkout --`/`clean -f`等破坏性操作来"顺手"清理提交前发现的问题,发现了就报告给用户决定
|