Husky 本地 Git 钩子守卫

问题：Git 钩子常常只在 CI 上存在

很多团队把校验只放进 CI：提交已经推送、PR 已经打开，才发现 lint 挂了、测试没跑、commit message 不符合约定。等到那时，错误信息已经离开开发者的机器，回滚和修复的成本都更高。Git 本身支持本地钩子，但 .git/hooks 目录不随仓库分发，换机器或初始化新 clone 后，这些保护常常就消失了。

这个技能做了什么

该技能围绕 Husky 展开，把 Git 钩子变成仓库内可追踪、可共享的配置。目标不是再造一套 CI，而是让 pre-commit、pre-push、commit-msg 这类检查在开发者本机，以及通过仓库工作的 Agent 执行时，都能先跑一遍。

它关注的核心能力包括：

• 将本地 Git 钩子接入 JavaScript 仓库，而不是依赖某台机器上的临时脚本
• 覆盖 pre-commit、pre-push、commit-msg 三个常见阶段，分别对应提交前、推送前和提交信息校验
• 让人类开发者与 Agent 面对同一套进入远端前的守卫条件
• 为后续接入现有工具链提供统一入口，例如 lint、格式化和测试脚本可以挂到对应钩子上

典型工作路径是：先确认环境满足 Git、Node.js 以及 npm / pnpm / yarn 之一；再把 Husky 配置纳入仓库；最后为不同钩子挂接实际检查命令。由于配置随代码维护，新克隆的仓库更容易获得一致的本地检查行为，而不是靠每个人记住执行哪条命令。

适用边界与注意点

这个技能解决的是离开工作站之前的拦截，不能替代 CI 里的完整验证，也不能替代分支保护、评审流程或发布流水线。它适合 JavaScript / Node.js 项目，尤其是希望把 lint、format、单测或 commit 规则前置到本地的团队。

实际使用时需要注意：项目必须已经引入 Husky 相关配置和钩子逻辑，技能才不会凭空生成项目里不存在的脚本。当前 SKILL.md 未能自动提取可用的安装与使用步骤，因此在敏感流程中运行前，应先审阅上游仓库，并对照 Husky 官方文档确认版本与目录约定。