提交前代码审查

为什么要在 commit 前做审查

很多缺陷和安全问题是在「已经写好、准备提交」之后才被发现：依赖漏洞、敏感信息泄露、风格与静态检查失败，往往要等到 CI 或同事 review 才暴露。若在本地提交前就能跑一轮有明确门禁的审查，可以把返工成本压到最低。

技能在做什么

该技能面向 pre-commit 场景，把「请求代码审查」变成可重复的工作流，而不是随口让模型扫一眼 diff：

• 安全扫描：在提交前检查常见安全风险与敏感模式（具体规则取决于你项目里接入的工具与策略）。
• 质量门禁：对静态检查、测试或项目自定义门槛做验证，未通过则不应视为「可提交」。
• 自动修复：对可安全自动处理的问题尝试修复（例如格式化、可确定的 lint 修复），减少无意义的来回。

典型节奏是：整理变更 → 触发审查 → 根据扫描与门禁结果处理 → 必要时应用 auto-fix 后再复查，直到满足提交条件。

适用边界

• 它不能替代人工设计评审、架构讨论或完整的 PR review；更适合作为提交前的自动化把关。
• 自动修复只应覆盖你信任、可回滚的变更；涉及业务逻辑或安全语义的问题仍需人工判断。
• 与 test-driven-development、github-code-review 等技能可组合：前者保证行为，后者覆盖协作与合并阶段的审查。