提交门控

问题在哪

本地 git commit 往往只扫一眼 diff 就提交：残留 console.log、误把 API key 打进仓库、改动超出当前任务范围，或者测试其实在红着。CI 发现问题时，提交早已进历史，回滚和排查成本都更高。

技能如何工作

Commit Gate 把「可以提交」当成校验通过的信号，在每次 commit 前跑一套轻量质量门，而不是替你做 code review。

1. Diff 审查：用 git diff --staged 看暂存区，查调试代码、敏感信息（密钥/令牌）、scope creep、误提交二进制等。
2. 按项目探测再验证：不硬编码命令——先看 package.json scripts、Makefile/Justfile、Cargo.toml，再选 bun test / npm test / vitest / cargo test、build、tsc --noEmit、lint 等。
3. 提交说明：按仓库习惯生成 message（如 Conventional Commits），英文祈使句，主题行 ≤72 字符，说明「为什么改」而不只是「fix bug」。

测试、构建或类型检查失败时必须阻断 commit；默认只本地提交，除非你明确说「提交并推送」。

边界与注意

• 若 verification-loop 已跑完全部检查，不要重复执行，直接走提交。
• 无 staged 文件、纯调研无代码变更：不触发门检。
• 仅文档（.md 等）或用户说「不要跑测试」：可做 diff + commit，跳过自动化验证。
• 项目本身有历史失败时，应区分「本次改动引入的新失败」与既有问题；只有前者应阻断。
• 与 harness-verification-loop 等上游技能衔接：验证完成后再交给 Commit Gate 做最后一道门。