Git Commit 是一个提交信息生成技能，用于生成以叙事为重点的 Conventional Commits 提交信息，并结合 Jira 工单上下文，然后提交和推送更改。
用途 该技能用于在提交代码时生成“能讲完整故事”的提交信息，便于日后进行代码考古（code archeology）。同时支持集成 Jira 工单上下文。
何时使用 当用户输入“commit”或“git commit”（带或不带斜杠命令）时；当用户说“commit this”或“let's commit”时；当用户要求创建提交信息时；当工作已完成并准备提交时；当用户提到提交或推送更改时，可激活该技能。
关键规则 绝不在 Git 提交信息中添加共同作者。绝不在提交信息中提及 Claude Code。
工作流程
- 收集上下文：先收集当前状态信息，包括当前 git status、当前 git diff（已暂存更改）、最近提交记录（用于提供上下文）以及当前分支。
- 提取 Jira 工单上下文（如适用）：从当前分支名中解析 Jira 工单 ID，支持的命名模式包括 PROJ-123-feature-name、feature/PROJ-123-description、PROJ-123。如果找到 Jira 工单 ID，使用 mcp__zapier__jira_software_cloud_find_issue_by_key 获取工单详情，获取标题、描述、验收标准、评论，并使用此上下文理解更改的更广泛目的。
- 人在回路——询问上下文：始终使用 AskUserQuestion 工具询问进行该更改的原因。基于 diff 和 Jira 上下文（如可用），生成 3-4 个合理的选项，说明进行该更改的可能原因，并以多选题形式呈现。示例问题为“Why did you make these changes?”，选项示例包括“Fix bug where X was causing Y”“Add new feature for Z”“Refactor to improve maintainability”，用户始终可选择“Other”提供自定义说明。选项应针对 diff 中观察到的实际更改，而非泛泛而谈；分析代码更改以推断可能的动机。等待用户回复，并将其说明纳入提交信息。
- 分析技术更改：审查已暂存的更改，从技术层面理解改了什么，包括修改的文件、添加/更新的函数、更改的依赖、配置更新。
- 创建增强提交信息：生成能为未来代码考古讲完整故事的提交信息。格式为：type(scope): 简洁的主题行，描述更改内容；随后分段说明“Why this change was needed”（纳入用户说明和 Jira 工单上下文）、“What changed”（修改的技术摘要）、“Problem solved”（说明所解决的业务/技术问题），如找到 Jira 工单则添加“Refs: PROJ-123”。
Conventional Commits 类型 feat：新功能；fix：缺陷修复；docs：文档更改；style：格式、缺少分号等；refactor：不改变功能的代码重构；test：添加或更新测试；chore：维护任务、依赖、构建流程；perf：性能改进；ci：持续集成更改。
- 执行提交和推送（需要确认） 不要使用 git add -A 或 git add .，只提交已暂存且已理解的 Wen 文件。用户必须确认后才能执行 git commit 或 git push；这些命令有意不放在 allowed-tools 列表中，因此会提示用户批准。在用户批准提交信息后，使用 heredoc 提交多行信息，然后执行推送。
叙事重点 创建提交信息时，应让未来的开发者在数月后进行代码考古时受益。信息应回答：改了什么（技术摘要）？为什么需要（业务上下文、用户说明）？解决了什么问题（来自 Jira 工单和用户输入）？如何与更大的功能/项目相关（Jira 上下文）？
示例 示例一（带 Jira 上下文的 feat 提交）展示了围绕工具执行超时处理的功能提交，包含 Why、What changed、Problem solved 以及 Refs: AGP-582。示例二（fix）展示了防止令牌刷新竞态条件的缺陷修复提交。示例三（refactor）展示了将验证逻辑提取到共享模块的重构提交。
重要说明 绝不要跳过“why”问题——用户上下文至关重要；多行提交使用 heredoc 以确保正确格式；在分支名中找到 Jira 工单时引用它；技术摘要要具体；为读者着想——有人可能在 6 个月后调试这段代码；不添加共同作者——绝不添加“Co-Authored-By”或提及 Claude Code。