setup-pre-commit

setup-pre-commit 技能概览

setup-pre-commit 是做什么的

setup-pre-commit 技能可以帮助智能体在 JavaScript 或 TypeScript 仓库里加上一套实用的 Git commit 门禁，通常会使用 husky、lint-staged、Prettier，以及可选的 typecheck 和 test 脚本。说得更直白一点，它会把“只处理已暂存文件的格式化”接进提交流程，并在有问题时先拦住不合格的 commit，避免直接落进仓库。

setup-pre-commit 最适合哪些人

这个技能最适合团队或个人开发者：你已经有一个现成仓库，想快速落一套稳定、省心的 pre-commit 配置，但又不想从零手写第一版 Husky。尤其适合已经是 Node 技术栈的项目，希望在 commit 时自动格式化，并顺带跑一些轻量质量检查的场景。

setup-pre-commit 真正解决的是什么问题

大多数用户要的其实不是“把 Husky 装上”，而是希望仓库里的贡献者能更放心地提交代码，并且有一个行为可预期的 hook，能够：

• 格式化已暂存文件，
• 在仓库本来就有 typecheck 和 test 脚本时顺手执行，
• 不额外发明新的工具链，
• 跟仓库当前使用的 package manager 保持一致。

这才是 setup-pre-commit 的实际价值。

setup-pre-commit 和通用提示词有什么不同

一个泛泛的提示词，往往会给出很多 Git hook 方案，选择空间大但落地不一定稳。setup-pre-commit skill 更聚焦，也更适合常见需求：按 Husky + lint-staged + Prettier 这条明确路径来搭，自动识别 package manager，创建正确的文件，并且避免把仓库实际上并不支持的 typecheck 或 test 命令硬塞进去。

setup-pre-commit 默认会搭出哪些内容

根据技能源码，预期输出通常包括：

• 初始化 husky
• 一个 .husky/pre-commit 文件
• 一个 .lintstagedrc
• 仅在仓库里还没有 Prettier 配置时才创建 .prettierrc
• hook 中接入 lint-staged，以及在脚本已存在时加入 typecheck 和 test

哪些仓库适合，哪些不太适合 setup-pre-commit

最适合：

• Node.js 仓库
• 前端或全栈 TypeScript 应用
• 已经使用 package.json 的仓库
• 已有 test 和 typecheck 脚本的项目

不太理想：

• 带有自定义 hook 编排逻辑的多语言 monorepo
• 已经在用其他 hook 管理器的仓库
• 希望 commit 流水线做到极快、极细粒度或强语言定制的团队
• 每次 commit 跑测试都会明显过慢的项目

如何使用 setup-pre-commit 技能

setup-pre-commit 技能的安装上下文

如果你使用的是 Skills 系统，可以从源仓库添加这个技能：

npx skills add mattpocock/skills --skill setup-pre-commit

之后在你希望智能体直接修改当前仓库时调用它，而不是让它抽象地解释 Git hooks 是什么。

setup-pre-commit 需要从你的仓库读取哪些输入

setup-pre-commit usage 的效果高度依赖仓库上下文。调用之前，最好确保智能体可以检查这些内容：

• package.json
• 任意 lockfile，例如 package-lock.json、pnpm-lock.yaml、yarn.lock 或 bun.lockb
• 现有的 Prettier 配置文件
• 现有的 .husky/ 或其他 Git hook 设置
• 是否存在 typecheck 和 test 脚本

如果缺少这些上下文，智能体很可能会生成与你的 package manager 或现有脚本不匹配的命令。

setup-pre-commit 首先该读哪个仓库文件

先看 SKILL.md。这个技能本身很简单，也比较自包含，关键逻辑都在这里：

• 检测 package manager
• 安装 husky、lint-staged 和 prettier
• 运行 npx husky init
• 写入 .husky/pre-commit
• 写入 .lintstagedrc
• 仅在缺失时新增 .prettierrc
• 验证结果

就这个技能而言，没有额外的辅助文件藏着隐藏逻辑。

怎样给 setup-pre-commit 下一个好提示词

一个较弱的提示词：

Set up pre-commit hooks.

一个更强的提示词：

Use the setup-pre-commit skill in this repo. Detect the package manager from lockfiles, inspect package.json, add Husky with lint-staged and Prettier, and only include typecheck or test in .husky/pre-commit if those scripts already exist. Do not overwrite any existing Prettier config. Show me the files you changed and the exact commands you ran.

为什么这个更好：

• 它明确锚定了 package manager 的判断规则，
• 能防止智能体凭空添加脚本，
• 能保留仓库现有的格式化约定，
• 并且要求给出可审阅的 diff。

如何把模糊目标改写成完整的 setup-pre-commit 请求

如果你的真实目标是“让我们的 Git workflow 更安全”，那最好把它进一步约束成跟仓库有关的具体条件：

• 当前使用的 package manager
• 测试是否足够快，适合放进 pre-commit
• 你只想做格式化，还是格式化加校验
• 仓库是否已经有 Prettier 或 Husky
• 你是否希望 hook 尽量精简，以保证贡献者提交速度

例如：

Use setup-pre-commit for Git Workflows in this React TypeScript repo. We use pnpm, already have a test script, and have typecheck in package.json. Keep the hook simple and fast. Reuse existing Prettier config if present. If tests look expensive, explain whether they should stay in pre-commit or move to pre-push.

这种提示词给到的是足够支持决策的仓库信息，而不只是一个模糊任务标签。

setup-pre-commit 预期会生成哪些文件和命令

对于一个常见的 npm 仓库，这个技能通常会引导出以下结果：

• 安装开发依赖：husky、lint-staged、prettier
• 运行 npx husky init
• 创建 .husky/pre-commit
• 创建 .lintstagedrc
• 视情况创建 .prettierrc

hook 内容应根据 package manager 做适配。技能源码里明确写了：凡是需要用到 npm 的地方，都应该替换成实际检测出来的 package manager。

setup-pre-commit 对 package manager 的实际处理方式

这个技能的 package manager 检测规则很直接：

• package-lock.json → npm
• pnpm-lock.yaml → pnpm
• yarn.lock → yarn
• bun.lockb → bun
• 无法明确判断时 → npm

这点很关键，因为很多失败的 setup-pre-commit install 尝试，问题并不出在 Husky 本身，而是文档、命令或生成文件里混用了不同的 package manager。

setup-pre-commit 会有意省略什么

这个技能有一个很有价值的边界：它不应该凭空发明仓库本来不支持的脚本。如果 package.json 里没有 typecheck 或 test，那么这些行就不该写进 .husky/pre-commit，并且应该明确告诉用户为什么没加。

这也让它比那些默认“每个项目都有 TypeScript 检查和测试”的宽泛提示词更安全。

运行 setup-pre-commit 之后，建议怎么验收

在智能体应用完这个技能后，建议你这样检查：

1. 检查 package.json
2. 检查 .husky/pre-commit
3. 检查 .lintstagedrc
4. 确认没有覆盖已有的 Prettier 配置
5. 用一个小的已暂存格式化改动做一次测试 commit
6. 决定 test 是否真的应该放在 pre-commit，而不是放到别处

最后这一步很重要：技术上正确，不等于使用体验合理。一个会跑很久测试的 hook 可能完全合法，但仍然会拖累团队采纳。

setup-pre-commit 的默认审查清单

在合并改动前，确认这些点：

• package manager 与仓库实际情况一致
• .husky/pre-commit 使用的是贡献者本地可运行的命令
• hook 没有调用不存在的脚本
• 通过 lint-staged 将格式化限制在已暂存文件范围内
• Prettier 配置只在缺失时才新增
• commit 延迟在日常使用中是可以接受的

setup-pre-commit 技能常见问题

setup-pre-commit 适合新手吗？

适合，前提是仓库是比较标准的 Node 项目。这个技能有一定预设，但并不复杂，而且能绕开很多第一次接 Husky 时最常见的坑，比如初始化方式和基础的 lint-staged 接线。

setup-pre-commit 不涵盖哪些内容？

这个技能不会替你设计一整套完整的代码质量策略。它不会帮你制定 ESLint 规则、优化 monorepo 的 hook 执行，也不会自动生成复杂的、按文件类型细分的 lint-staged 命令。它的职责范围就是：把初始的 commit hook 先搭起来。

什么情况下不该用 setup-pre-commit？

以下情况建议跳过：

• 你的仓库已经有成熟的 Git hook 体系，
• 你需要脱离 Node 工具链的、多步骤语言专用 hooks，
• 你想要高度定制的 staged-file 匹配模式，
• 每次 commit 都跑测试显然会拖慢开发者节奏。

在这些情况下，更定制化的提示词，或者团队内部现成标准，通常会更合适。

它比直接让 AI “set up Husky” 更好吗？

针对这个具体场景，通常是更好的。setup-pre-commit 的价值不在“新奇”，而在“受约束的执行方式”。它把一条合理的默认路径编码进来了，能减少 lockfile 检测、脚本缺失判断、以及何时创建 Prettier 配置这些地方的猜测空间。

setup-pre-commit 能用于 monorepo 吗？

有时可以，但要谨慎。如果仓库有一个清晰的顶层 package.json，并且 hook 策略是统一的，它依然能帮上忙。但如果各个 package 有独立脚本、不同格式化策略，或者 workspace 各自有不同的测试命令，那它的可靠性就会下降。

如果仓库已经有格式化配置，setup-pre-commit 还会强行加 Prettier 吗？

不会。源码说明里写得很清楚：只有在不存在任何 Prettier 配置时，才创建 .prettierrc。这一点对落地很友好，也很重要。

setup-pre-commit 能否用于超出格式化范围的 Git Workflows？

可以，但能力是有限的。这个技能支持在相关脚本已经存在时，把 typecheck 和 test 纳入 commit workflow。但它并不是一个完整的分支保护或 CI 设计工具。

如何把 setup-pre-commit 技能用得更好

一开始就给 setup-pre-commit 更强的仓库事实

提升 setup-pre-commit usage 效果最快的方法，就是在提示词里直接给出明确的仓库信号：

• package manager
• 是否存在 typecheck
• 是否存在 test
• 测试是否足够快
• 是否已经有 Prettier 配置
• 是否已经有 .husky/

当技能建立在已验证事实之上，而不是建立在猜测之上时，可靠性会明显提高。

要求一种“以 diff 为中心”的实现方式

一个很强的改进型提示词是：

Use the setup-pre-commit skill, but minimize changes. Reuse existing config where possible, avoid replacing current hook behavior, and show the exact file diff before writing anything risky.

这在仓库里已经有部分相关工具时尤其有用。

避免最常见的 setup-pre-commit 失败模式

最常见的失败方式，就是往 hook 里加了仓库根本跑不起来的命令。要提高结果质量，可以明确告诉智能体：

Only add typecheck and test to the hook if those scripts already exist in package.json. Otherwise omit them and explain why.

这条要求与技能源码完全一致，也能有效避免提交流程被弄坏。

为开发速度调优，而不只是追求“技术上正确”

很多团队最后都会发现，把 npm run test 放进 pre-commit 太重了。如果速度很重要，可以要求智能体评估 hook 成本：

Use setup-pre-commit, but if tests appear slow or broad, explain whether they should move to pre-push or CI instead of pre-commit.

这样一来，这个技能就不只是“装工具”，而是真正去适配你的工作流。

明确要求生成 package-manager-safe 的命令

如果团队使用的是 pnpm、yarn 或 bun，即便仓库里已经有 lockfile，也建议在提示词里明确写出来。这样能进一步消除歧义，并提升生成 hook 文件和后续操作说明时的命令一致性。

让智能体保留仓库现有标准

如果仓库里已经有格式化或 hook 相关文件，可以补上这句：

Do not overwrite existing Prettier or Husky config without comparing and explaining the merge strategy.

这比看上去更重要。很多 pre-commit 工具落地失败，不是技术问题，而是因为它太激进地替换了团队本地已有约定。

用验证步骤提升输出质量

一个更好的收尾提示词可以是：

After applying setup-pre-commit, verify that the hook files exist, dependencies are in devDependencies, and the hook references only valid scripts. Then tell me how to test it with one staged file.

这样可以把智能体从“只是把文件写出来”，推进到“确保真的可用”。

setup-pre-commit 第一轮结果出来后继续迭代

如果第一版输出技术上没错，但用起来别扭，可以继续用这些跟进指令细化：

• “Make the hook faster.”
• “Adapt this for pnpm.”
• “Remove test from pre-commit but keep typecheck.”
• “Keep existing Prettier settings and only add missing pieces.”
• “Adjust for a monorepo root package.”

相比重新给一个全新而宽泛的提示词，这种增量迭代通常更有效。

用户最在意的 setup-pre-commit 结果是什么

对大多数采用者来说，最好的 setup-pre-commit guide 重点并不在“它安装了多少工具”，而在于它是否：

• 能立刻适配当前仓库，
• 不会把 commit 流程弄坏，
• 尊重现有配置，
• 速度足够快，开发者愿意长期开着用。

带着这些目标去使用这个技能，它更有可能真正产生长期价值。