# 提示词：生成提交信息与 PR 描述

> 让智能体根据暂存区 diff 和近期提交风格写提交信息，再生成包含背景、改动、测试与风险的 PR 描述，写清楚没验证到的内容，不夸大。

## 适用场景

改完代码，要写提交信息和 PR 描述。智能体很会写，但默认产出常有三个毛病：把「做了什么」写成流水账；用「大幅提升」「全面优化」这类夸大的词；声称「已测试」，实际上没有跑过。

这份提示词要求它先学习仓库已有的提交风格，只根据 diff 里的事实描述，并且把「没有验证的部分」明确写出来。

## 模板

```text
请为我当前的改动生成提交信息，并起草 PR 描述。先不要执行 git commit 或 git push，也不要创建 PR。

准备工作：
1. 运行 git status 和 git diff --staged（如果暂存区为空，用 git diff），读懂全部改动。
2. 运行 git log -n 15 --oneline，学习这个仓库的提交信息风格（语言、前缀、长度），并沿用。
3. 检查有没有混进无关改动、调试代码、密钥或大文件；有的话先告诉我，不要继续。

提交信息要求：
- 第一行不超过 50 个字，概述「改了什么」，不要以句号结尾。
- 需要时空一行，再用 1 到 3 行写「为什么改」和关键取舍，不要复述 diff 的每一行。
- 只写 diff 里能看到的事实；不要使用「优化」「提升」「完善」这类没有信息量的词，
  能写出具体数据或行为变化就写。
- 如果这次改动应该拆成多个提交，告诉我怎么拆，每个提交包含哪些文件。

PR 描述按下面的结构输出：
## 背景
为什么要做这件事，关联的 Issue 或需求【编号或链接】。
## 改动
按模块列出主要改动，每条一句话。
## 如何验证
我实际运行过的命令和结果；没有运行过的，明确写「未验证」，不要写「应该没问题」。
## 风险与回滚
可能受影响的功能、数据或接口；如何回滚。
## 截图或说明（界面改动时）
我会自己补充，你留出位置。

最后列出你不确定的地方，等我确认。
```

## 怎么用 / 怎么改

1. 把模板存成团队共享的提示词，或者做成 Skill：只要把正文放进 `SKILL.md`，就可以用 `/commit-msg` 之类的命令随时调用。
2. 想一步到位时，在末尾改成「我确认后，用 git commit 提交；然后用 gh pr create 创建 PR」。官方文档也说明，你可以直接对 Claude 说「create a pr」让它创建，并在之后让它补充描述里的上下文。
3. 团队有固定规范（例如约定式提交、必须带 Issue 编号）时，把规范写进项目的 CLAUDE.md，而不是每次粘贴到提示词里。
4. 把第 2 步换成你们团队的真实例子，让它按例子写，比抽象的格式说明有效。

## 常见问题或注意事项

- **和内置的提交行为冲突。** Claude Code 自带了一套提交和 PR 的说明。如果你在 CLAUDE.md 里另立规则，两者可能打架。官方给出的做法是用设置项 `includeGitInstructions` 去掉内置说明，用 `attribution` 自定义署名文本。具体取值以设置参考文档为准。
- **署名行不想要或者必须要。** 同样通过 `attribution` 设置，而不是在提示词里反复叮嘱。
- **不要让它自动提交。** 提交会改变仓库状态。在你确认内容前，保持「只生成、不执行」；需要的话可以在权限规则里对 `git push` 设为询问。
- **PR 描述需要你补的内容。** 动机、业务背景、踩过的坑，智能体看 diff 是看不到的。把它当作草稿，补完再提交。
- **Claude 创建的 PR 会关联会话。** 通过 `gh pr create` 创建后，可以用 `claude --from-pr 编号` 找回当时的会话，方便后续追问。