setup-pre-commit

setup-pre-commitスキルの概要

setup-pre-commitでできること

setup-pre-commitスキルは、husky、lint-staged、Prettier、さらに必要に応じて typecheck と test スクリプトを使い、JavaScript / TypeScript リポジトリに実用的な Git のコミット前チェックを追加するためのスキルです。要するに、ステージ済みファイルに対して整形を自動でかけつつ、問題のあるコミットが混ざる前に止められる状態を作ります。

このスキルが向いている人

このスキルは、既存リポジトリに手堅い pre-commit 設定を入れたいチームや個人開発者に向いています。特に、最初の Husky 設定を自力で一から設計したくない場合に相性がよく、Node ベースのプロジェクトで、コミット時のフォーマットと軽めの品質チェックを追加したいときに使いやすいです。

本当に解決したい仕事は何か

多くのユーザーが欲しいのは、単に「Husky が入っている状態」ではありません。求めているのは、コントリビューターが安心してコミットできるリポジトリであり、そのために必要なのは次のような予測可能なフックです。

• ステージ済みファイルを整形する
• typecheck と test スクリプトが存在する場合だけ実行する
• 余計なツールを勝手に増やさない
• リポジトリで使っているパッケージマネージャーに合わせる

これが setup-pre-commit の実務的な価値です。

汎用プロンプトと違う点

汎用的なプロンプトだと、Git hook の実装パターンをいくつも提案してきがちです。一方、setup-pre-commit スキルは用途をかなり絞っていて、そのぶん実用的です。具体的には、Husky + lint-staged + Prettier という定番構成を前提に、パッケージマネージャーを検出し、必要なファイルを作成し、リポジトリが実際には対応していない typecheck や test を勝手に追加しないようになっています。

デフォルトでセットアップされるもの

スキルの内容を見る限り、想定される出力は次のとおりです。

• husky の初期化
• .husky/pre-commit ファイル
• .lintstagedrc
• 既存の Prettier 設定がない場合に限った .prettierrc
• lint-staged 用の hook コマンド、さらに既存スクリプトがある場合のみ typecheck と test

相性のよいリポジトリ・合わないリポジトリ

相性がよいケース:

• Node.js リポジトリ
• フロントエンド、またはフルスタックの TypeScript アプリ
• すでに package.json を使っているリポジトリ
• test と typecheck スクリプトが既にあるプロジェクト

あまり向かないケース:

• 独自の hook オーケストレーションを持つ polyglot モノレポ
• すでに別の hook マネージャーを使っているリポジトリ
• デフォルト以上に高速・選択的・言語特化のコミットパイプラインを求めるチーム
• 毎回のコミットでテストを回すには重すぎるプロジェクト

setup-pre-commitスキルの使い方

setup-pre-commitスキルを導入する前提

Skills システムを使っている場合は、まずソースリポジトリからスキルを追加します。

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

そのうえで、Git hook の一般論を説明させるのではなく、今開いているリポジトリを実際に変更してほしいときに呼び出してください。

リポジトリ側で必要になる入力情報

setup-pre-commit の使い勝手は、リポジトリの文脈がどれだけ見えているかでかなり変わります。呼び出す前に、少なくともエージェントが次を確認できる状態にしておくと安全です。

• package.json
• package-lock.json、pnpm-lock.yaml、yarn.lock、bun.lockb などの lockfile
• 既存の Prettier 設定ファイル
• 既存の .husky/ や Git hook の仕組み
• typecheck と test スクリプトの有無

この情報がないと、実際のパッケージマネージャーやスクリプトに合わないコマンドを出してしまう可能性があります。

最初に読むべきリポジトリファイル

最初に見るべきなのは SKILL.md です。このスキルはシンプルで自己完結しており、重要なロジックはそこにまとまっています。

• パッケージマネージャーを検出する
• 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.

これが良い理由:

• パッケージマネージャーの判定ルールを明示できる
• 存在しないスクリプトの捏造を防げる
• 既存のフォーマット方針を守れる
• 差分をレビューしやすくなる

曖昧な目的を実行可能な依頼に変えるには

本当の目的が「Git の運用を安全にしたい」なら、そのまま投げるのではなく、リポジトリ固有の制約に落とし込むのが大事です。

• 使っているパッケージマネージャー
• テストが pre-commit に載せられる速度か
• フォーマットだけでよいのか、検証も入れたいのか
• すでに Prettier や Husky が入っているか
• コントリビューターの速度を優先して最小構成にしたいか

例:

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.

このレベルで渡すと、単なる作業指示ではなく、判断に必要な情報までそろった依頼になります。

想定されるファイルとコマンド

一般的な npm リポジトリなら、このスキルの結果として次の内容になることが多いです。

• 開発依存に husky、lint-staged、prettier を追加
• npx husky init を実行
• .husky/pre-commit を作成
• .lintstagedrc を作成
• 必要なら .prettierrc を作成

hook の中身は、使っているパッケージマネージャーに合わせて変える必要があります。ソースのスキルでも、必要に応じて npm を検出したパッケージマネージャーに置き換えるよう明記されています。

実際のパッケージマネージャー判定ルール

このスキルのパッケージマネージャー判定はシンプルです。

• package-lock.json → npm
• pnpm-lock.yaml → pnpm
• yarn.lock → yarn
• bun.lockb → bun
• 判定できない場合 → npm

ここは意外と重要です。雑な setup-pre-commit 導入が失敗する原因は、Husky 自体ではなく、ドキュメントや生成ファイルの中でパッケージマネージャーのコマンドが混ざってしまうことが多いためです。

あえて追加しないもの

このスキルには明確な境界があります。リポジトリがもともとサポートしていないスクリプトを勝手に作らないことです。package.json に typecheck や test がなければ、それらの行は .husky/pre-commit に入れず、その理由をユーザーに明示するべきです。

この点は、「どのプロジェクトにも TypeScript チェックとテストがあるはず」と決め打ちしがちな広いプロンプトより安全です。

setup-pre-commit実行後のおすすめ確認フロー

エージェントがスキルを適用したら、次の順で確認すると実務で失敗しにくくなります。

1. package.json を確認する
2. .husky/pre-commit を確認する
3. .lintstagedrc を確認する
4. 既存の Prettier 設定が上書きされていないことを確認する
5. 小さなフォーマット変更をステージしてテストコミットする
6. test を pre-commit に残すべきか、別の場所に移すべきか判断する

最後の判断は特に重要です。正しく動くことと、運用しやすいことは別です。長いテストを走らせる hook は技術的には正しくても、チームに定着しないことがあります。

マージ前の実用的なレビューチェックリスト

変更をマージする前に、次を確認してください。

• パッケージマネージャーがリポジトリと一致している
• .husky/pre-commit のコマンドをローカルで実行できる
• 存在しないスクリプトを hook が呼んでいない
• ステージ済みファイルの整形が lint-staged で限定されている
• Prettier 設定は、未設定のときだけ追加されている
• 日常運用に耐えるコミット速度になっている

setup-pre-commitスキル FAQ

setup-pre-commitは初心者にも向いていますか？

はい。標準的な Node プロジェクトであれば向いています。多少の方針は持っていますが複雑ではなく、Husky の初期化や基本的な lint-staged 接続で最初につまずきやすいポイントをかなり避けられます。

setup-pre-commitがカバーしない範囲は？

このスキルは、コード品質戦略全体を設計するものではありません。ESLint ルールの選定、モノレポでの hook 実行最適化、ファイル種別ごとの複雑な lint-staged コマンド設計までは行いません。スコープは、あくまで最初のコミットフックのセットアップです。

setup-pre-commitを使わないほうがよいのはいつですか？

次のような場合は見送ったほうがよいです。

• すでに成熟した Git hook の仕組みがある
• Node ツールチェーン外で、言語固有の多段 hook が必要
• ステージ済みファイルのパターンをかなり細かくカスタマイズしたい
• 毎回のコミットでテストを回すと明らかに開発速度が落ちる

こうしたケースでは、このスキルよりも、要件に合わせた個別プロンプトや社内標準のほうが適しています。

AIに「Husky を設定して」と頼むより良いですか？

この用途に限れば、たいていは良いです。setup-pre-commit の価値は目新しさではなく、制約の効いた実行にあります。lockfile の判定、存在しないスクリプトへの配慮、Prettier 設定を作るべきかどうかといった判断を、妥当なデフォルトに沿って進められるのが強みです。

モノレポでもsetup-pre-commitは使えますか？

場合によります。注意して使う必要があります。トップレベルに明確な package.json が 1 つあり、hook の戦略も一本化されているなら役立つことがあります。一方で、各パッケージが独自スクリプトを持つ、整形ポリシーが別々、workspace ごとにテストコマンドが違うといった構成では、信頼性は下がります。

既存のフォーマット設定があってもPrettierを強制しますか？

いいえ。ソースの指示では、既存の Prettier 設定がない場合にだけ .prettierrc を作ることになっています。この挙動は導入しやすさの面でかなり重要です。

フォーマット以外のGit Workflowsにも使えますか？

はい。ただし限定的です。既存の typecheck と test スクリプトがある場合に、それらをコミットフローへ追加するところまでは対応できます。ブランチ保護や CI 全体の設計まで担うツールではありません。

setup-pre-commitスキルを改善するには

最初にリポジトリの事実をしっかり渡す

setup-pre-commit の使い勝手を最も手早く改善する方法は、プロンプトの時点でリポジトリの具体情報を渡すことです。

• パッケージマネージャー
• typecheck の有無
• test の有無
• テストが速いかどうか
• 既存の Prettier 設定があるか
• 既存の .husky/ があるか

推測ではなく確認済みの事実をもとに動けると、スキルの信頼性は大きく上がります。

差分を意識した実装を求める

改善用の強いプロンプトとしては、たとえば次が有効です。

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.

部分的にすでにツールが入っているリポジトリでは、こうした依頼が特に効きます。

もっとも多い失敗を防ぐ

一番ありがちな失敗は、そのリポジトリでは実行できないコマンドを追加してしまうことです。次のように明示しておくと結果が安定します。

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

これはソーススキルの方針とも一致しており、壊れたコミットフローを防げます。

正しさだけでなく開発速度も最適化する

多くのチームは、pre-commit での npm run test が重すぎると後から気づきます。速度が重要なら、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.

こうすると、「ツールを入れる」だけでなく「実際の運用に合う形にする」段階まで踏み込めます。

パッケージマネージャー安全なコマンドを明示的に要求する

チームで 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.

これにより、単にファイルを作るだけで終わらず、実際に使える状態まで確認させられます。

最初の結果を見てから調整する

1 回目の出力が技術的には正しくても、運用しにくいことはあります。その場合は、次のような追加入力で調整するほうが効果的です。

• “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 を使うと、単なる導入作業で終わらず、継続的な価値につながりやすくなります。