# Commit Message Writer

> 根据已暂存或即将提交的改动，写出符合 Conventional Commits 规范的提交信息。当用户说"帮我写个 commit message"、"这次改动怎么写提交信息"、"git commit 写什么"、"帮我总结一下这次改动"时使用。也适用于用户直接贴出一段 diff 或改动描述、要求生成提交信息的场景。不负责实际执行 `git commit`，只负责生成信息文本；不负责代码评审（那是 code-review-checklist 的职责）。

- Skill: `fengyan3141/commit-message-writer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fengyan3141/commit-message-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fengyan3141/commit-message-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fengyan3141 (https://skillmd.com/u/fengyan3141)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fengyan3141/commit-message-writer

---


# commit-message-writer

## 目标

给出一条清楚、可扫描、符合 [Conventional Commits](https://www.conventionalcommits.org/) 规范的提交信息，让以后看 `git log` 的人（包括写代码的人自己）一眼知道这次改动做了什么、为什么做。

## 使用步骤

1. **拿到改动内容**。优先运行 `git diff --staged`（已暂存的改动）；如果什么都没暂存，运行 `git diff` 看未暂存的改动；如果两者都是空的，直接问用户改了什么，不要凭空编。
2. **判断改动类型**，选一个最贴切的 type：
   - `feat`：新增用户可见的功能
   - `fix`：修复缺陷
   - `refactor`：不改变外部行为的内部重构
   - `docs`：只改文档
   - `test`：只改测试
   - `chore`：构建脚本、依赖升级、配置等杂项
   - `perf`：性能优化
   一次改动如果明显跨越多个类型，选影响最大的那个作为主 type，其余在正文里说明，不要为了凑规范硬拆成好几条不相关的信息。
3. **写 subject 行**：`<type>(<可选 scope>): <祈使句概述>`，例如 `fix(auth): 修正 token 过期后未清理本地状态的问题`。要求：
   - 祈使语气（"修正"而不是"修正了"，"add"而不是"added"），控制在 72 个字符以内。
   - 说清楚"做了什么"，不要只说"修改 xxx.js"这种没有信息量的话。
4. **判断要不要写正文**：改动影响面大、有非显而易见的原因、或者未来的人可能会问"为什么这么改"时，加一段正文说明动机和取舍；纯粹的小修小补（改个错别字、调整格式）不需要正文。
5. **不要编造改动里没有的内容**。看不到的信息（比如具体 issue 编号、外部背景）就不要往里加，除非用户明确提供。

## 输出格式

直接给出可以复制粘贴到 `git commit -m` 或编辑器里的最终文本，不要额外包一层解释，除非用户问起为什么这么写。多行正文时保持 subject 和正文之间空一行（符合 git 提交信息的标准格式）。

## 边界

- 不执行 `git commit`、`git push` 等实际操作，只生成文本内容。
- 不评审代码质量或找 bug，只描述改动本身。
- 拿不到实际 diff 时如实告诉用户，不要凭猜测编写提交信息。