pre-commit-check

提交前检查

这是严格的准则。 请严格遵守以下规则。

每次提交前，仅针对已暂存的文件检查以下三道关卡。三道关卡必须全部通过。

---

关卡 1：安全性

委派给 security-checklist 技能。扫描已暂存的文件，检查是否存在：

• 硬编码的机密信息、API 密钥、令牌、密码
• 含有真实值的 .env 文件
• 凭据、私钥、连接字符串

如果发现任何问题：停止。不要继续检查关卡 2。

---

关卡 2：代码质量

依据 core-principles 和标准最佳实践检查已暂存的文件：

• DRY — 此次更改是否重复了其他地方已有的逻辑？检查是否存在复制粘贴的代码，以及应当提取的重复模式。
• 纯函数 — 辅助函数是否为纯函数且可测试？副作用是否已隔离？
• 快速失败 — 不要使用静默默认值。缺少配置或数据时应抛出错误，而不是回退。
• 命名 — 变量、函数和文件的命名是否清晰？
• 关注点分离 — 业务逻辑是否与 I/O 或呈现逻辑混杂？
• 错误处理 — 是否在恰当的层级捕获错误，并提供可用于采取行动的上下文？
• 死代码 — 是否遗留了 console.log、已注释掉的代码块或未使用的导入？

报告问题。可以指出轻微的风格问题，但不应因此阻止提交。

---

关卡 3：会导致故障吗？

提交前，请自问：推送后，哪些问题会导致故障，而单元测试又无法发现？

单元测试会自动运行——此关卡关注的是测试遗漏的问题：运行时环境问题、缺少权限、基础设施配置错误、部署故障。

务必检查：

• 代码能否构建？运行构建。
• 现有测试是否通过？运行测试。
• 是否存在 Linter 错误？运行 Linter。

基础设施代码（Lambdas、CDK、SST）——大多数推送后的故障都源于此：

• 部署到开发环境并直接调用 Lambda。
• 检查 CloudWatch，查看是否存在缺失的环境变量、权限错误或导入失败。
• 验证新增的 SSM 参数或机密信息在目标环境中确实存在。
• Lambda 即使通过了所有单元测试，调用时仍可能失败。务必调用它。

前端：

• 页面是否能正常呈现，且没有控制台错误？
• 页面能否在浏览器中加载？

依赖 CI 的更改（工作流、构建配置）：

• 如果可行，请在本地运行相关步骤（构建命令、测试套件、Linter）。

原则： 如果验证用时不到 2 分钟，就现在执行。不要抱着侥幸心理推送并寄望于 CI 发现问题。

---

输出

报告发现时，请使用以下格式：

🔴 Blocked — [reason, e.g. "hardcoded API key in config.ts"]
🟡 Fix before commit — [code quality issue with file reference]
✅ Verified — [what was tested, e.g. "build passes, Lambda invoked successfully"]

---

持续改进

如果开发者纠正了此技能本应阻止的行为，请建议对此技能进行具体修改，以避免未来再次出现相同的纠正。