name: draft-commit description: 根据暂存变更创建周到、支持性的提交信息。

起草提交信息

根据暂存变更创建周到、支持性的提交信息。

欢迎

编写好的提交信息是一门艺术。这项技能帮助你以清晰、友好的方式捕捉变更的本质，你的未来自己（和团队成员）将会感激。

你的暂存变更讲述了一个故事。让我们一起写下这个故事。

你在做什么

你将要做的是：

审查你暂存的内容
理解变更的性质
创建一个既能捕捉“做了什么”又能捕捉“为什么这么做”的提交信息
复制该信息并在提交时使用

工作原理

步骤 1：分析暂存变更

首先，我们将使用 git diff --cached 查看你的暂存变更。

这向我们展示：

哪些文件改变了：你修改了哪些文件？
它们内部改变了什么：添加了行？删除了行？重构了？
模式：我们能检测出你在做什么工作吗？

步骤 2：理解意图

从变更中，我们推断：

工作类型：功能？错误修复？重构？文档？
范围：系统的哪个部分？
影响：什么得到了改进？这实现了什么？

步骤 3：起草信息

我们精心设计一条信息，使其：

具体：不是“更新文件”，而是“添加 StandardsRepository 抽象”
解释原因：不仅仅是改变了什么，而是为什么重要
展现信心：你的变更值得庆祝
易于理解：未来的读者能理解你的意图

步骤 4：与你分享

我们展示起草的信息，以便你可以：

审查它
复制它
在你的 git commit 命令中使用它

配置

加载配置

该技能从 .claude/skills/draft-commit/config.json 读取：

style：信息的语气（“supportive” 或 “concise”）
format：信息结构（“descriptive” 或 “conventional”）
messageLength：详细程度（“concise” 或 “detailed”）
includeContext：添加上下文解释（true/false）
includeFileCounts：显示文件/行数（true/false）

自定义行为

编辑 config.json 以更改默认值：

{
  "style": "supportive",         // 或 "concise"
  "format": "descriptive",       // 或 "conventional"
  "messageLength": "concise",    // 或 "detailed"
  "includeContext": true,
  "includeFileCounts": true
}

流程

获取暂存变更

运行：git diff --cached
返回：统一差异格式的所有暂存变更

分类变更

分析差异以理解：

添加的文件、删除的文件、修改的文件
添加的行数、删除的行数
变更模式（新功能、错误修复、重构、文档等）

推断工作类型

根据模式，检测：

feat — 新功能
fix — 错误修复
docs — 文档变更
refactor — 代码结构改进
test — 测试添加/变更
chore — 依赖项更新、配置变更
style — 格式化、清理
perf — 性能改进

确定范围

识别系统的哪个部分：

受影响的组件
变更的模块
受影响的功能

起草信息

对于支持性风格 + 描述性格式

模板：

[对你所做工作的简要描述]

[为什么这很重要 — 什么得到了改进或它实现了什么]

[可选：如果有帮助，提供更多上下文]

[可选：如果配置了，显示文件计数]

示例：

添加 StandardsRepository 抽象

将标准访问集中到单一、可靠的接口中。
这消除了重复，使系统更易于维护。

文件：
- 新增：lib/standards-repository.md, lib/schemas/standards-schema.json
- 修改：7 个 agent/skill 文件更新以使用新模式

原因：标准分散在多个文件中，造成了重复和耦合。现在有一种清晰的方式通过验证来访问标准。

对于简洁风格

模板：

[简洁描述]

[如果需要，简要上下文]

示例：

集中标准访问

分散在 7 个文件中的标准现在使用单一存储库模式。

对于约定式格式

模板：

[类型]: [描述]

[为什么这很重要 / 附加上下文]

示例：

refactor: 使用存储库模式集中标准访问

将标准加载整合到单一接口中。
消除重复并提高可测试性。

输出格式

该技能像这样显示起草的信息：

## 📝 起草的提交信息

[实际信息，准备复制]

---

## 如何使用它

1. 复制上面的信息
2. 暂存你的变更：`git add .`（或选择特定文件）
3. 创建提交：`git commit -m "你的信息"`

或粘贴到编辑器的提交信息提示中。

---

**已分析变更**：
- [X 个文件] 已更改
- [+Y 行] 已添加
- [-Z 行] 已删除

重要说明

这个功能做什么

仅分析你的暂存变更
为你起草一条信息以供审查
在聊天中显示信息以便轻松复制
不会自动提交

这个功能不做什么

不会进行提交（由你完成）
不会暂存变更（由你完成）
不会修改你的仓库

为什么这很重要

这让你保持控制。你：

仔细暂存你的变更
查看我们的建议
决定是否正确
自己进行提交

错误处理

如果我们遇到问题：

没有暂存变更：我们会通知你并建议先暂存
意图不明确：我们会要求澄清或提供建议
配置问题：我们会使用默认值并通知你

优秀提交信息的技巧

有意暂存：将相关变更分组在一起
小提交：更容易理解和审查
具体：“添加验证”而不是“更新文件”
原因很重要：解释推理，而不仅仅是变更
现在时态：“添加功能”而不是“已添加功能”

示例

示例 1：功能添加

暂存变更：新函数 + 测试 + 文档

起草的信息：

添加用户认证模块

实现基于 JWT 的 API 认证。
包括令牌生成、验证和刷新逻辑。

文件：
- auth/jwt-handler.ts（主要实现）
- auth/__tests__/jwt-handler.test.ts（全面测试）
- docs/AUTHENTICATION.md（使用指南）

原因：启用安全的 API 访问。为基于角色的访问控制提供基础。

示例 2：错误修复

暂存变更：修复了错误处理程序中的错误

起草的信息：

修复 API 响应中间件中的错误处理

错误消息没有被正确序列化，导致 500 错误
显示为格式错误的 JSON。现在返回干净的错误对象。

文件：
- middleware/error-handler.ts（修复了序列化）
- __tests__/error-handler.test.ts（添加了测试用例）

这修复了问题 #245。

示例 3：文档

暂存变更：添加了 README 和指南

起草的信息：

记录设置和部署过程

添加全面指南：
- 本地开发设置
- 运行测试
- 生产构建
- 部署程序

文件：
- SETUP.md（新增）
- DEPLOYMENT.md（新增）
- README.md（更新了链接）

原因：新贡献者需要清晰的指导。这减少了达到生产力所需的时间。

配置示例

对于约定式提交

{
  "style": "concise",
  "format": "conventional",
  "messageLength": "concise",
  "includeContext": true,
  "includeFileCounts": false
}

输出：feat: 添加认证模块

对于详细信息

{
  "style": "supportive",
  "format": "descriptive",
  "messageLength": "detailed",
  "includeContext": true,
  "includeFileCounts": true
}

输出：长而详细的信息，包含完整上下文

对于简洁更新

{
  "style": "concise",
  "format": "descriptive",
  "messageLength": "concise",
  "includeContext": false,
  "includeFileCounts": false
}

输出：简短、切中要点的信息

故障排除

问：如果我暂存了错误的变更怎么办？ 答：使用 git reset HEAD <文件> 取消暂存它们，然后再次运行 /dac。

问：我可以编辑起草的信息吗？ 答：当然！复制它，编辑它，然后使用你的版本。它只是一个草稿！

问：这适用于约定式提交吗？ 答：是的！在 config.json 中设置 format: "conventional"。

问：我可以为每个项目配置不同的设置吗？ 答：是的！每个项目的 config.json 是独立的。只需编辑文件。

与 HQB 的集成

该技能展示了 HQB 模式：

支持性语气：指导而不评判
专注清晰：一个明确的目的
体贴的方法：尊重你的自主权
技能架构：可重用、可配置的逻辑

使用此功能后的后续步骤

复制起草的信息
再次审查你的变更
使用 git commit -m "你的信息" 进行提交
继续构建很棒的东西！