commit-staged

创建提交

按照项目规范完成创建提交的完整工作流。

明确调用时若附带额外文本，请将其视为有关更改的补充背景信息，并纳入提交规划和提交消息。 如果会话历史中包含发现、动机或理由，请在提交消息正文中写入最重要的内容，而不要只依赖差异内容。

流程

首先，对暂存区差异运行 /simplify 技能，并在提交前应用其建议。仅涉及文档的差异无需处理。

1. 优先执行方式

   • 如果有可用的子 Agent，请使用 github-dev:commit-creator 完成整个工作流。
   • 将任何额外的调用文本作为补充背景信息一并传递。
   • 否则，请按照以下手动步骤操作。

2. 仅分析暂存文件

   • 检查所有暂存文件：git diff --cached --name-only
   • 查看差异：git diff --cached
   • 完全忽略未暂存的更改。

3. 提交消息格式

   • 第一行：{type}: 简短描述（最多 50 个字符）
   • 类型：feat、fix、refactor、docs、style、test、build
   • 使用直白的语言。避免行话、流行语和仓库内部简称，除非需要使用准确的命令或工具名称。
   • 如有可用的会话历史发现和动机，请加以利用。
   • 侧重“为什么”，而不是“做了什么”。
   • 尽可能采用 1 句符合惯例的描述，再加 1–2 句简短的动机或发现。
   • 对于复杂更改，在空行后添加项目符号列表。

4. 消息示例

   • feat: add sign-in flow
   • fix: stop duplicate jobs on save
   • docs: add skills install snippets

5. 更新文档

   • 检查 README.md，确认是否存在以下情况：
     • 应当记录的新功能
     • 与当前实现不符的过时描述
     • 新依赖缺少安装说明
   • 根据暂存的更改按需更新。

6. 执行

   • 使用 HEREDOC 语法提交，以确保格式正确。
   • 验证提交消息格式正确。
   • 不要在提交消息中添加测试计划。

最佳实践

• 先分析暂存文件，再编写提交消息。
• 第一行保持在 50 个字符以内。
• 使用主动语态。
• 在准确的前提下尽量使用简单词语。
• 优先采用会话中的发现，而不是重复原始差异的细节。
• 每个提交只包含一个逻辑更改。
• 确保 README 与实现保持一致。