Pre-Commit Check 是一个用于提交前审查的严格规则集，其核心要求是：在任何 commit 之前，只针对已暂存的文件进行审查，并且必须通过三道关卡（Gate），三者全部通过方可提交。
第一关：安全（Security） 此关委托给 security-checklist 技能，扫描暂存文件中的以下内容：硬编码的密钥、API key、token、密码；包含真实值的 .env 文件；凭据、私钥、连接字符串。如果发现上述内容，必须停止，不得继续进入第二关。
第二关：代码质量（Code Quality） 依据 core-principles 和标准最佳实践审查暂存文件，关注点包括：DRY——本次改动是否重复了其他地方已有的逻辑，检查复制粘贴的代码、应被提取的重复模式；纯函数——辅助函数是否纯净且可测试，副作用是否被隔离；快速失败——不应有静默默认值，配置或数据缺失时应抛出错误而不是回退；命名——变量、函数、文件命名是否清晰；关注点分离——业务逻辑是否与 I/O 或展示层混在一起；错误处理——错误是否在正确层级被捕获并带有可操作的上下文；死代码——是否存在遗留的 console.log、被注释掉的代码块或未使用的 import。发现问题后应报告，风格上的小问题可以记录，但不应该阻塞提交。
第三关：会不会出问题（Will It Break?） 在提交前要问：push 之后什么会出问题，而单元测试捕捉不到？单元测试会自动运行，所以这一关针对的是它们遗漏的内容：运行时环境问题、权限缺失、基础设施配置错误、部署失败。
始终要做的事：代码能否构建，运行构建；已有测试是否通过，运行它们；是否存在 linter 错误，运行 linter。
基础设施代码（Lambda、CDK、SST）——大多数 push 后的失败来自这里：部署到 dev 并直接调用 Lambda；检查 CloudWatch，查看是否有缺失的环境变量、权限错误或 import 失败；确认任何新的 SSM 参数或密钥确实存在于目标环境中。Lambda 可以通过所有单元测试，但在调用时仍然失败，所以要始终调用它。
前端：是否在没有控制台错误的情况下渲染；页面能否在浏览器中加载。
依赖 CI 的改动（workflow、构建配置）：如果可能，在本地运行相关步骤（构建命令、测试套件、lint）。
规则是：如果验证耗时少于 2 分钟，现在就做。不要 push 之后指望 CI 来抓问题。
输出格式 报告发现时使用以下格式：🔴 Blocked——[原因，例如 "hardcoded API key in config.ts"]；🟡 Fix before commit——[带文件引用的代码质量问题]；✅ Verified——[已测试的内容，例如 "build passes, Lambda invoked successfully"]。
渐进式改进 如果开发者纠正了本技能本应阻止的行为，应建议对本技能做具体修订，以防止将来出现同样的纠正。
适用场景与限制：该技能适用于准备提交代码、或 git-commits 技能触发时的场景。其明确限定只审查已暂存的文件，且以三道关卡为准。资料中未提供安装方式、收费信息、支持平台等细节。