该技能定义了三层质量策略，用于划分 Git hooks 与编辑后 hooks 在修复（Fix）和验证（Verify）上的分工。核心原则是：能在 pre-commit / pre-push 中作为关口拦住的问题，以 Git hooks 为准；编辑后 hooks（AI 智能体或编辑器的项目 hooks）只用于编辑后的自动修复与早期检测。
三层模型：编辑后 hooks 负责 Fix 与早期检测，不阻塞提交（fail-open）；pre-commit 作为验证关口，可阻止 git commit；pre-push 执行较重的检查，可阻止 git push。以 pre-commit 为正本，是因为它对人工提交、AI 智能体外部的编辑器和 CLI 同样有效，是唯一能统一阻止 commit / push 的公共层。
分工上，format、lint、type check、schema / migration 的修复放在编辑后 hooks，仅处理被编辑的文件，不做全仓库批量修复；对应的整体检验（format check、整体 lint、check、密钥扫描、测试）放在 pre-commit 或 pre-push。不要用编辑后 hooks 对同一验证做关口，早期检测可以，但不应据此阻止提交。
实现要点：lint / format / check 的命令定义应统一到项目任务（如 mise run 等），CI、pre-commit 与编辑后 hooks 调用同一任务名，避免重复定义；使用 pre-commit 框架时显式声明 stages: [pre-commit] 与 stages: [pre-push]，将 gitleaks 等放在 pre-commit 专用、完整测试放在 pre-push 专用；hook 安装集中到 hooks-install 类任务。编辑后 hooks 需 fail-open，从输入获取 file_path，对不相关扩展名 no-op，仅运行 Fix 类命令；Tab 编辑后 hook 仅在工具支持时配置。具体配置依赖所用工具，如 Cursor 使用 .cursor/hooks.json，其他工具按其项目 hooks 规范，正本是事件概念（after agent edit / after tab edit）。
应避免的反模式包括：在编辑后 hooks 中把 format:check 或整体 lint 设为关口；pre-commit 与编辑后 hooks 使用不同命令定义；仅靠编辑后 hooks 阻止提交；把 pre-push 级别的重检查塞进 pre-commit。资料未提供具体安装命令与示例代码。