setup-pre-commit

Überblick über den setup-pre-commit-Skill

Was setup-pre-commit macht

Der setup-pre-commit-Skill hilft einem Agenten dabei, in einem JavaScript- oder TypeScript-Repository eine praxistaugliche Git-Commit-Schranke einzurichten – mit husky, lint-staged, Prettier sowie optionalen typecheck- und test-Skripten. Konkret sorgt er dafür, dass formatierte Änderungen auf gestagten Dateien automatisch ausgeführt werden und fehlerhafte Commits abgefangen werden können, bevor sie im Repository landen.

Für wen dieser Skill am besten geeignet ist

Dieser Skill passt besonders gut für Teams oder Solo-Entwickler, die in einem bestehenden Repo ein unkompliziertes Pre-Commit-Setup wollen und die erste Husky-Konfiguration nicht von Hand entwerfen möchten. Er eignet sich vor allem dann, wenn bereits ein Node-basiertes Projekt vorhanden ist und beim Commit sowohl Formatierung als auch leichte Qualitätsprüfungen laufen sollen.

Worum es in der Praxis wirklich geht

Die meisten Nutzer wollen nicht einfach nur „Husky installiert haben“. Sie wollen ein Repo, in dem Contributions mit gutem Gefühl committet werden können – mit einem verlässlichen Hook, der:

• gestagte Dateien formatiert,
• vorhandene typecheck- und test-Skripte ausführt, wenn sie existieren,
• keine zusätzliche Tooling-Landschaft erfindet,
• zum Paketmanager des Repos passt.

Genau darin liegt der praktische Nutzen von setup-pre-commit.

Was setup-pre-commit von einem generischen Prompt unterscheidet

Ein allgemeiner Prompt könnte viele verschiedene Git-Hook-Varianten vorschlagen. Der setup-pre-commit-Skill ist enger gefasst und für einen häufigen Anwendungsfall nützlicher: Er richtet gezielt den Pfad aus Husky + lint-staged + Prettier ein, erkennt den Paketmanager, erstellt die richtigen Dateien und vermeidet es, typecheck- oder test-Kommandos hinzuzufügen, die das Repo gar nicht unterstützt.

Was standardmäßig eingerichtet wird

Laut Skill-Quelle gehört typischerweise Folgendes zum erwarteten Ergebnis:

• Initialisierung von husky
• eine Datei .husky/pre-commit
• eine .lintstagedrc
• eine .prettierrc nur dann, wenn noch keine bestehende Prettier-Konfiguration vorhanden ist
• Hook-Kommandos für lint-staged sowie typecheck und test, sofern diese Skripte bereits existieren

Geeignete und ungeeignete Repos

Gut geeignet:

• Node.js-Repos
• Frontend- oder Full-Stack-TypeScript-Apps
• Repos, die bereits package.json verwenden
• Projekte mit vorhandenen test- und typecheck-Skripten

Weniger ideal:

• polyglotte Monorepos mit eigener Hook-Orchestrierung
• Repos, die bereits einen anderen Hook-Manager verwenden
• Teams, die sehr schnelle, stark selektive oder sprachspezifische Commit-Pipelines jenseits der Defaults wollen
• Projekte, bei denen Tests bei jedem Commit zu langsam wären

So verwendest du den setup-pre-commit-Skill

Installationskontext für den setup-pre-commit-Skill

Wenn du das Skills-System verwendest, füge den Skill aus dem Quell-Repository hinzu:

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

Rufe ihn anschließend auf, wenn der Agent das aktuelle Repository ändern soll – nicht, wenn er Git Hooks nur abstrakt erklären soll.

Welche Eingaben der setup-pre-commit-Skill aus deinem Repo braucht

Die Qualität der setup-pre-commit-Nutzung hängt stark vom Repo-Kontext ab. Bevor du ihn aufrufst, sollte der Agent Folgendes prüfen können:

• package.json
• eine vorhandene Lockfile wie package-lock.json, pnpm-lock.yaml, yarn.lock oder bun.lockb
• bestehende Prettier-Konfigurationsdateien
• vorhandenes .husky/ oder eine bestehende Git-Hook-Einrichtung
• ob typecheck- und test-Skripte existieren

Ohne diesen Kontext kann es passieren, dass der Agent Kommandos erzeugt, die nicht zu deinem Paketmanager oder deinen Skripten passen.

Welche Repository-Datei du zuerst lesen solltest

Starte mit SKILL.md. Dieser Skill ist einfach und in sich geschlossen; die entscheidende Logik steht vollständig dort:

• Paketmanager erkennen
• husky, lint-staged und prettier installieren
• npx husky init ausführen
• .husky/pre-commit schreiben
• .lintstagedrc schreiben
• .prettierrc nur dann hinzufügen, wenn sie fehlt
• das Ergebnis verifizieren

Für diesen konkreten Skill gibt es keine zusätzlichen Helper-Dateien mit verstecktem Verhalten.

So promptest du setup-pre-commit sinnvoll

Ein schwacher Prompt:

Set up pre-commit hooks.

Ein stärkerer Prompt:

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.

Warum das besser ist:

• es verankert die Regel zur Paketmanager-Erkennung,
• verhindert erfundene Skripte,
• bewahrt bestehende Formatierungsstandards,
• fordert eine nachvollziehbare Diff-Ansicht an.

Wie du aus einem groben Ziel eine vollständige Anfrage machst

Wenn dein eigentliches Ziel lautet „unseren Git-Workflow sicherer machen“, dann formuliere es als repo-spezifische Randbedingungen:

• verwendeter Paketmanager
• ob Tests schnell genug für pre-commit sind
• ob du nur Formatierung oder Formatierung plus Validierung möchtest
• ob das Repo bereits Prettier oder Husky nutzt
• ob der Hook im Interesse der Contributor-Geschwindigkeit bewusst minimal bleiben soll

Beispiel:

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.

So bekommt der Agent Informationen, mit denen er gute Entscheidungen treffen kann – nicht nur ein allgemeines Task-Label.

Erwartete Dateien und Kommandos

Für ein normales npm-Repo führt der Skill meist zu Folgendem:

• Dev-Dependencies installieren: husky, lint-staged, prettier
• npx husky init ausführen
• .husky/pre-commit erstellen
• .lintstagedrc erstellen
• gegebenenfalls .prettierrc erstellen

Der Inhalt des Hooks sollte an den Paketmanager angepasst werden. Der Skill sagt explizit, dass npm dort, wo nötig, durch den erkannten Paketmanager ersetzt werden soll.

Praktisches Verhalten bei unterschiedlichen Paketmanagern

Die Regel zur Paketmanager-Erkennung im Skill ist bewusst einfach:

• package-lock.json → npm
• pnpm-lock.yaml → pnpm
• yarn.lock → yarn
• bun.lockb → bun
• wenn unklar → npm

Das ist wichtig, weil viele schlechte setup-pre-commit-Installationsversuche nicht an Husky selbst scheitern, sondern an gemischten Paketmanager-Kommandos in Doku oder generierten Dateien.

Was der Skill bewusst weglässt

Eine sinnvolle Grenze dieses Skills: Er soll keine Skripte erfinden, die dein Repo nicht ohnehin schon unterstützt. Wenn package.json weder typecheck noch test enthält, sollten diese Zeilen in .husky/pre-commit weggelassen werden – und der Nutzer sollte explizit darauf hingewiesen werden.

Das macht den Skill sicherer als breite Prompts, die stillschweigend davon ausgehen, dass jedes Projekt eine TypeScript-Prüfung und einen Test-Runner hat.

Empfohlener Workflow nach dem Ausführen des Skills

Nachdem der Agent den Skill angewendet hat:

1. package.json prüfen
2. .husky/pre-commit prüfen
3. .lintstagedrc prüfen
4. bestätigen, dass keine vorhandene Prettier-Konfiguration überschrieben wurde
5. einen Test-Commit mit einer kleinen gestagten Formatierungsänderung ausführen
6. entscheiden, ob test wirklich in pre-commit gehört oder besser an eine andere Stelle verschoben werden sollte

Der letzte Punkt ist wichtig: Korrektheit ist nicht dasselbe wie gute Ergonomie. Ein Hook, der lange Tests ausführt, kann technisch korrekt sein und trotzdem die Akzeptanz im Team verschlechtern.

Eine gute Standard-Checkliste für das Review

Vor dem Merge solltest du prüfen:

• der Paketmanager passt zum Repo
• .husky/pre-commit verwendet Kommandos, die Contributors lokal ausführen können
• der Hook ruft keine fehlenden Skripte auf
• Formatierung bleibt durch lint-staged auf gestagte Dateien begrenzt
• Prettier-Konfiguration wurde nur hinzugefügt, wenn sie fehlte
• die Commit-Latenz ist für den täglichen Einsatz akzeptabel

FAQ zum setup-pre-commit-Skill

Ist setup-pre-commit auch für Einsteiger geeignet?

Ja, sofern das Repo ein normales Node-Projekt ist. Der Skill ist meinungsstark, aber nicht kompliziert, und nimmt viel von der typischen Anfangsreibung rund um Husky-Initialisierung und die grundlegende Verdrahtung von lint-staged ab.

Was deckt setup-pre-commit nicht ab?

Der Skill versucht nicht, eine vollständige Code-Quality-Strategie zu entwerfen. Er wählt keine ESLint-Regeln aus, optimiert keine Hook-Ausführung für Monorepos und erstellt keine ausgefeilten dateitypspezifischen lint-staged-Kommandos. Sein Umfang ist das initiale Commit-Hook-Setup.

Wann sollte ich setup-pre-commit nicht verwenden?

Lass ihn weg, wenn:

• dein Repo bereits ein ausgereiftes Git-Hook-System hat,
• du sprachspezifische, mehrstufige Hooks außerhalb des Node-Toolings brauchst,
• du sehr individuell angepasste Patterns für gestagte Dateien willst,
• Tests bei jedem Commit Entwickler offensichtlich ausbremsen würden.

In solchen Fällen ist ein stärker zugeschnittener Prompt oder ein vorhandener interner Standard meist die bessere Wahl.

Ist das besser, als eine KI einfach zu bitten, „Husky einzurichten“?

Für genau diesen Anwendungsfall meistens ja. Der Wert von setup-pre-commit liegt nicht in Originalität, sondern in der klaren Begrenzung. Der Skill kodiert einen sinnvollen Standardpfad und reduziert Rätselraten bei Lockfile-Erkennung, fehlenden Skripten und der Frage, wann eine Prettier-Konfiguration angelegt werden sollte.

Funktioniert setup-pre-commit auch für Monorepos?

Manchmal, aber mit Vorsicht. Er kann weiterhin hilfreich sein, wenn das Repo ein klar definiertes package.json auf Top-Level-Ebene und eine einheitliche Hook-Strategie hat. Weniger verlässlich ist er, wenn Packages eigene Skripte, getrennte Formatierungsregeln oder workspace-spezifische Test-Kommandos haben.

Erzwingt der Skill Prettier, auch wenn das Repo bereits Formatierungs-Config hat?

Nein. Laut Quellanweisung soll .prettierrc nur erstellt werden, wenn noch keine bestehende Prettier-Konfiguration vorhanden ist. Das ist ein wichtiges, einführungsfreundliches Verhalten.

Kann ich setup-pre-commit für Git-Workflows jenseits der Formatierung nutzen?

Ja, aber nur in begrenztem Rahmen. Der Skill unterstützt dabei, typecheck und test in den Commit-Workflow aufzunehmen, wenn diese Skripte bereits existieren. Er ist jedoch kein vollwertiges Werkzeug für Branch-Protection oder CI-Design.

So verbesserst du den setup-pre-commit-Skill

Gib dem setup-pre-commit-Skill frühzeitig belastbare Repo-Fakten

Der schnellste Weg, die setup-pre-commit-Nutzung zu verbessern, ist ein Prompt mit konkreten Signalen aus dem Repo:

• Paketmanager
• ob typecheck existiert
• ob test existiert
• ob Tests schnell sind
• ob bereits eine Prettier-Konfiguration existiert
• ob .husky/ bereits vorhanden ist

Der Skill wird deutlich verlässlicher, wenn er auf bestätigten Fakten statt auf Annahmen arbeitet.

Bitte um eine diff-orientierte Umsetzung

Ein starker Verbesserungs-Prompt ist:

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.

Das hilft besonders in Repos, die bereits Teile des benötigten Toolings enthalten.

Vermeide den häufigsten Fehlerfall

Der häufigste Fehler besteht darin, Kommandos hinzuzufügen, die das Repo gar nicht ausführen kann. Die Ergebnisse werden besser, wenn du dem Agenten explizit sagst:

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

Diese Anweisung entspricht dem Skill-Design und verhindert kaputte Commits.

Optimiere auf Entwicklergeschwindigkeit, nicht nur auf Korrektheit

Viele Teams merken erst später, dass npm run test in pre-commit zu schwergewichtig ist. Wenn Geschwindigkeit wichtig ist, bitte den Agenten, die Hook-Kosten mitzudenken:

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.

So wird aus „Tooling installieren“ eher „den Workflow passend gestalten“.

Bitte um paketmanager-sichere Kommandos

Wenn dein Team pnpm, yarn oder bun verwendet, sag das ausdrücklich dazu – selbst dann, wenn die Lockfile vorhanden ist. Das reduziert Mehrdeutigkeit und verbessert die Konsistenz der Kommandos in generierten Hook-Dateien und Folgeanweisungen.

Bitte den Agenten, bestehende Standards zu bewahren

Wenn dein Repo bereits Formatierungs- oder Hook-Dateien hat, ergänze:

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

Das ist wichtiger, als es klingt. Pre-Commit-Tooling scheitert im Team oft nicht technisch, sondern sozial – weil lokale Konventionen zu aggressiv ersetzt werden.

Verbessere die Ausgabequalität mit einem Validierungsschritt

Ein besserer finaler Prompt enthält:

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.

Damit wird der Agent über das bloße Erstellen von Dateien hinaus auf tatsächliche Nutzbarkeit verpflichtet.

Iteriere nach dem ersten Durchlauf

Wenn das erste Ergebnis technisch stimmt, aber unpraktisch wirkt, helfen oft diese Nachfragen:

• „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.“

Das ist in der Regel effektiver, als mit einem komplett neuen, sehr breiten Prompt von vorn zu beginnen.

Worauf Nutzer am meisten achten

Für die meisten Anwender ist ein guter setup-pre-commit-Leitfaden nicht die Frage, „wie viele Tools er installiert“, sondern ob er:

• sofort mit dem aktuellen Repo funktioniert,
• keine Commits kaputtmacht,
• bestehende Konfiguration respektiert,
• schnell genug bleibt, damit Entwickler ihn aktiviert lassen.

Wenn du den Skill mit genau diesen Ergebnissen im Blick verwendest, ist die Chance deutlich höher, dass er dauerhaft echten Mehrwert liefert.