setup-pre-commit

setup-pre-commit 概览

setup-pre-commit skill 可以帮你搭建一套实用的 Git hook 工作流：在提交前运行 Husky pre-commit 检查、用 lint-staged 配合 Prettier 做格式化，并可选地在代码进入 commit 之前执行 typecheck/test。它最适合那些已经有 Node 技术栈、需要一套快速且可重复的配置，而不是手工自己拼 hook 的仓库。

setup-pre-commit 的用途

当你想在 commit 时加一道安全网，统一格式并尽早发现明显问题时，就该用 setup-pre-commit skill。它真正要解决的不是孤立地“安装 Husky”，而是在不迫使你重构仓库的前提下，让本地提交更安全。

什么时候它最适合用

如果你的仓库已经在使用，或者可以使用 Prettier、typecheck 和 test 脚本，并且你希望这套约定能在 npm、pnpm、Yarn 或 Bun 之间保持一致，那么它就很合适。它也适用于你需要在现有项目里快速落地、且尽量少争论规范的场景。

什么时候它的局限比较明显

如果你的项目不是 Node 技术栈，或者你要的是 commit-msg / pre-push 逻辑而不是 pre-commit，或者你的检查需要比简单 hook 更复杂的编排，这个 skill 就没那么适用。它也默认你愿意先确认仓库里到底有哪些脚本，再把它们加进 hook。

如何使用 setup-pre-commit skill

安装并打开正确的文件

使用 npx skills add mattpocock/skills --skill setup-pre-commit 安装。然后先看 SKILL.md，因为真正的工作流和决策点都写在里面。如果你的目录视图只显示一个文件，那也足够按流程设置，但你仍然应该检查仓库树，找出包管理器和脚本相关的线索。

提供正确的仓库上下文

为了获得最佳结果，请告诉这个 skill 当前用了哪个 lockfile、package.json 里是否已经有 typecheck 和 test、以及 Prettier 是否已经配置好。一个更有质量的请求像这样：“Set up setup-pre-commit in this repo using pnpm; keep existing Prettier config; add only the scripts that already exist.” 这比简单说“加 pre-commit hooks”要好，因为它消除了包管理器和 hook 内容上的猜测空间。

按正确顺序执行工作流

这个 skill 的设计流程很简单：识别 package manager、安装开发依赖、初始化 Husky、写入 .husky/pre-commit、添加 lint-staged，以及创建或复用 Prettier 配置。实际操作中，最重要的决定是要不要把 npm run typecheck 和 npm run test 放进 hook；如果这些脚本不存在，就应当省略。这样 hook 才会实用，而不是脆弱。

实用的提示词模板

提示词要明确说明仓库现状和你希望执行的策略。例如：“Use setup-pre-commit to add Husky, lint-staged, and Prettier to this monorepo. The lockfile is pnpm-lock.yaml, typecheck exists, test does not, and there is already a .prettierrc.” 这样 skill 才有足够信息产出正确配置，而不会凭空捏造脚本或覆盖现有配置。

setup-pre-commit skill 常见问题

setup-pre-commit 只适合新仓库吗？

不是。setup-pre-commit skill 在现有仓库里往往更有价值，因为它能帮你在不手工重建文件的情况下，补上一套一致的 hook 策略。它最适合你已经清楚现有脚本和配置的场景。

我需要同时用 Husky 和 lint-staged 吗？

在这套工作流里，需要，这正是它的重点。Husky 负责触发 hook，lint-staged 负责把格式化范围限制在已暂存文件上，让提交保持足够快。如果你只需要其中一部分，用通用提示词可能比 setup-pre-commit skill 更简单。

它会覆盖我的 Prettier 配置吗？

如果使用得当，不应该会。这个 skill 只有在缺少 .prettierrc 时才会创建它，核心判断在于你仓库里是否已经有需要保留的 formatter 配置。如果你已经有既定的风格策略，最好明确说明。

它更适合 CI，还是只适合本地提交？

它的主要价值是本地 pre-commit 强制检查，但同样的检查通常也会贴近 CI 的预期。如果你的 CI 使用的是不同命令，就不要机械照搬 hook；要让 hook 对齐流水线实际运行的脚本。这也是 setup-pre-commit for CI Troubleshooting 里最需要注意的问题。

如何改进 setup-pre-commit skill

把仓库的真实限制告诉它

提升质量最大的办法，就是明确告诉 setup-pre-commit 当前仓库已经存在什么包管理器、脚本和配置文件。缺少这些上下文，容易导致命令前缀写错、生成不必要的脚本，或者 hook 在第一次提交时就失败。

避免常见的 hook 失败

最常见的失败模式，是把 typecheck 或 test 加进 .husky/pre-commit，但这些脚本其实不存在。另一个常见问题是把所有文件都格式化，而不是只处理 staged files，这会让提交速度明显变慢。若你希望 hook 稳定可靠，就要明确说明当脚本缺失时应该怎么处理。

用明确目标提升首次输出质量

不要只说要安装什么，要直接说清楚你想要的结果。更好的指令是：“Add Husky pre-commit hooks that run lint-stagedon staged files, preserve the existing Prettier config, and includetypecheckonly ifpackage.json already defines it.” 这样得到的 setup-pre-commit guide 结果会比泛泛的请求更可用。

在第一轮之后继续迭代

初始设置完成后，检查 hook 是否符合团队对速度和严格度的预期。如果觉得太重，就把昂贵的检查从 pre-commit 移到 CI；如果觉得太松，就补上缺失的脚本，或者缩小 lint-staged 的作用范围。最好的 setup-pre-commit install 结果，是团队真的愿意一直用下去的那一版。