commit

你负责创建简短、易读且符合仓库现有惯例的 Git 提交消息。

仅当 rules/convention-detection.md 达到 Tier 3，且清单与之匹配时，才加载生态系统指南：references/go.md、references/swift.md、references/python.md、references/systems.md。

规则概览

规则	影响	文件
惯例检测	HIGH	rules/convention-detection.md
消息格式	HIGH	rules/message-format.md
提交类型选择	HIGH	rules/commit-type.md
问题引用	MEDIUM	rules/issue-references.md
变更范围	MEDIUM	rules/change-scope.md

提交前安全检查

每次提交前，使用项目的密钥扫描器扫描暂存的变更。默认使用 GitLeaks；如果项目已在使用 TruffleHog，也可以使用它。

1. 暂存后运行扫描器，将暂存差异通过管道传入其标准输入模式 — GitLeaks：git diff --cached | gitleaks stdin --redact --verbose；TruffleHog：git diff --cached | trufflehog stdin --results=verified,unknown --fail（包含 unknown，以确保 TruffleHog 无法在线验证的凭据也会阻止提交，与 GitLeaks 的行为一致）。通过管道传入可让 git 保持为普通命令，因此在隔离工作树的会话中可以接受；gitleaks git 和 trufflehog git 会将 git 作为操作数传递，因此在此类会话中会被拒绝。
2. 如果扫描器报告泄漏，立即停止 — 不要提交。报告发现的问题，并请用户移除密钥（如果密钥曾被推送，还应轮换密钥）。
3. 如果未安装密钥扫描器（找不到命令），不要擅自安装。如果项目的提交前钩子会运行扫描器，则提交并让钩子执行扫描。否则，告知用户当前没有可用的扫描器，建议安装一个（例如 brew install gitleaks 或同类工具），并在未经扫描前询问用户是否仍要提交。

提交时，绝不要编辑 .husky/、commitlint 或其他项目工具。如果缺少提交前钩子，请报告此情况，并指引用户使用 setup 技能，而不要自行配置。

工作流程

收到提交请求后，只暂存并提交 — 绝不能拉取、暂存到 stash、恢复 stash 或重写项目工具。

1. 显示当前 git status 并分析所有变更
2. 检测仓库的提交惯例（参见 rules/convention-detection.md）
3. 检查对话上下文中的问题引用（参见 rules/issue-references.md）
4. 评估变更范围（参见 rules/change-scope.md）
5. 仅暂存本次变更明确相关的路径 — 绝不要将无关修改一并全部暂存
6. 根据分支上下文选择提交类型或开头动词，而不能仅依据暂存的差异（参见 rules/commit-type.md）
7. 执行上述提交前安全检查
8. 按照 rules/message-format.md 创建提交消息

如果惯例检测来自 Tier 3 或 Tier 4 — 即来自生态系统默认惯例或普通回退规则，而非强制工具或明确的历史记录 — 请说明采用了哪种惯例以及原因，以便发现可能的错误判断。