setup-pre-commit

Visión general de la skill setup-pre-commit

Qué hace setup-pre-commit

La skill setup-pre-commit ayuda a un agente a añadir una barrera práctica antes del commit en un repositorio JavaScript o TypeScript usando husky, lint-staged, Prettier y, de forma opcional, scripts de typecheck y test. En la práctica, conecta el formateo de archivos staged y puede bloquear commits problemáticos antes de que lleguen al repositorio.

Para quién encaja mejor esta skill

Esta skill encaja especialmente bien para equipos o desarrolladores individuales que quieren una configuración de pre-commit sencilla y sin complicaciones en un repo existente, y no quieren diseñar a mano una primera configuración de Husky. Funciona especialmente bien si ya tienes un proyecto basado en Node y buscas formateo en el momento del commit junto con comprobaciones ligeras de calidad.

El trabajo real que resuelve

La mayoría de los usuarios no solo quieren “instalar Husky”. Quieren un repo en el que se pueda hacer commit con confianza, con un hook predecible que:

• formatee los archivos staged,
• ejecute scripts existentes de typecheck y test cuando estén presentes,
• no invente tooling adicional,
• respete el package manager del repo.

Ese es el valor práctico de setup-pre-commit.

Qué diferencia a setup-pre-commit de un prompt genérico

Un prompt genérico podría sugerir muchos patrones posibles para Git hooks. La setup-pre-commit skill es más concreta y útil para un caso muy habitual: configurar la ruta específica de Husky + lint-staged + Prettier, detectar el package manager, crear los archivos correctos y evitar añadir comandos de typecheck o test que el repo en realidad no soporta.

Qué configura por defecto

Según la fuente de la skill, la salida esperada incluye:

• inicialización de husky
• un archivo .husky/pre-commit
• un .lintstagedrc
• un .prettierrc solo si no existe ya una configuración de Prettier
• comandos del hook para lint-staged, además de typecheck y test cuando esos scripts ya existen

Repos donde mejor encaja y donde no tanto

Mejor encaje:

• repos Node.js
• aplicaciones TypeScript frontend o full-stack
• repos que ya usan package.json
• proyectos con scripts existentes de test y typecheck

Menos ideal:

• monorepos políglotas con orquestación personalizada de hooks
• repos que ya usan otro gestor de hooks
• equipos que quieren pipelines de commit muy rápidos, muy selectivos o específicos por lenguaje más allá de lo que trae por defecto
• proyectos donde ejecutar tests en cada commit resulta demasiado lento

Cómo usar la skill setup-pre-commit

Contexto de instalación de la skill setup-pre-commit

Si estás usando el sistema de Skills, añade la skill desde el repositorio de origen:

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

Después invócala cuando quieras que el agente modifique el repositorio actual, no cuando solo quieras una explicación abstracta sobre Git hooks.

Qué entradas necesita la skill de tu repo

La calidad de setup-pre-commit usage depende del contexto del repo. Antes de invocarla, asegúrate de que el agente puede inspeccionar:

• package.json
• cualquier lockfile como package-lock.json, pnpm-lock.yaml, yarn.lock o bun.lockb
• archivos de configuración existentes de Prettier
• cualquier configuración existente de .husky/ o de Git hooks
• si existen scripts de typecheck y test

Sin ese contexto, el agente puede generar comandos que no coincidan con tu package manager o con los scripts reales del proyecto.

El archivo del repositorio que conviene leer primero

Empieza por SKILL.md. Esta skill es simple y autocontenida, y toda la lógica importante está ahí:

• detectar el package manager
• instalar husky, lint-staged y prettier
• ejecutar npx husky init
• escribir .husky/pre-commit
• escribir .lintstagedrc
• añadir .prettierrc solo si falta
• verificar el resultado

En esta skill concreta no hay archivos auxiliares adicionales con comportamiento oculto.

Cómo dar un buen prompt para setup-pre-commit

Un prompt flojo:

Set up pre-commit hooks.

Un prompt mejor:

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.

Por qué este funciona mejor:

• fija la regla del package manager,
• evita scripts inventados,
• preserva las convenciones de formateo existentes,
• pide un diff que se pueda revisar.

Cómo convertir un objetivo difuso en una petición completa

Si tu objetivo real es “hacer más seguro nuestro flujo de Git”, conviértelo en restricciones específicas del repo:

• package manager en uso
• si los tests son lo bastante rápidos para pre-commit
• si quieres solo formateo o formateo más validación
• si el repo ya tiene Prettier o Husky
• si quieres que el hook sea mínimo para favorecer la velocidad de los contribuidores

Ejemplo:

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.

Ese prompt le da al agente información útil para decidir bien, no solo una etiqueta de tarea.

Archivos y comandos esperables

En un repo npm normal, la skill setup-pre-commit normalmente llevará a:

• instalar dependencias de desarrollo: husky, lint-staged, prettier
• ejecutar npx husky init
• crear .husky/pre-commit
• crear .lintstagedrc
• posiblemente crear .prettierrc

El contenido del hook debería adaptarse al package manager. La skill de origen indica explícitamente que hay que reemplazar npm por el package manager detectado cuando corresponda.

Comportamiento práctico según el package manager

La regla de detección de package manager de la skill es sencilla:

• package-lock.json → npm
• pnpm-lock.yaml → pnpm
• yarn.lock → yarn
• bun.lockb → bun
• si no está claro → npm

Esto importa porque muchos intentos pobres de setup-pre-commit install no fallan por Husky en sí, sino por mezclar comandos de distintos package managers en la documentación o en los archivos generados.

Lo que la skill omite a propósito

Un límite útil: la skill no debe inventar scripts que tu repo no soporta ya. Si package.json no tiene typecheck o test, esas líneas deben quedar fuera de .husky/pre-commit, y además hay que decírselo explícitamente al usuario.

Eso hace que la skill sea más segura que los prompts amplios que asumen que todos los proyectos tienen comprobación de TypeScript y test runner.

Flujo recomendado después de ejecutar la skill

Después de que el agente aplique la skill:

1. inspecciona package.json
2. inspecciona .husky/pre-commit
3. inspecciona .lintstagedrc
4. confirma que no se haya sobrescrito ninguna configuración existente de Prettier
5. prueba un commit con un pequeño cambio de formato en staged
6. decide si test debe ir en pre-commit o si conviene moverlo a otro punto

Este último paso es importante: corrección no es lo mismo que ergonomía. Un hook que ejecuta tests largos puede ser técnicamente válido y aun así perjudicar la adopción.

Un buen checklist de revisión por defecto

Antes de fusionar los cambios, verifica:

• que el package manager coincida con el repo
• que .husky/pre-commit use comandos que los contribuidores puedan ejecutar localmente
• que el hook no invoque scripts inexistentes
• que el formateo de staged esté limitado mediante lint-staged
• que la configuración de Prettier solo se haya añadido si faltaba
• que la latencia al hacer commit sea aceptable para el uso diario

Preguntas frecuentes sobre la skill setup-pre-commit

¿La skill setup-pre-commit es buena para principiantes?

Sí, si el repo es un proyecto Node estándar. La skill tiene criterio propio, pero no es complicada, y evita gran parte de la fricción habitual de una primera configuración con la inicialización de Husky y el cableado básico de lint-staged.

¿Qué no cubre setup-pre-commit?

La skill no intenta diseñar una estrategia completa de calidad de código. No elige reglas de ESLint, no optimiza la ejecución de hooks en monorepos ni crea comandos sofisticados de lint-staged específicos por tipo de archivo. Su alcance es la configuración inicial del hook de commit.

¿Cuándo no debería usar setup-pre-commit?

Mejor sáltatela si:

• tu repo ya tiene un sistema maduro de Git hooks,
• necesitas hooks multietapa específicos por lenguaje fuera del tooling de Node,
• quieres patrones de archivos staged muy personalizados,
• ejecutar tests en cada commit va a ralentizar claramente al equipo.

En esos casos, suele ser mejor un prompt más adaptado o un estándar interno ya existente.

¿Es mejor que pedirle a una IA “set up Husky”?

Normalmente sí para este caso de uso concreto. El valor de setup-pre-commit no está en la novedad, sino en la ejecución acotada. Codifica una ruta por defecto razonable y reduce las suposiciones en torno a la detección del lockfile, los scripts faltantes y cuándo crear configuración de Prettier.

¿Funciona setup-pre-commit en monorepos?

A veces, pero con cautela. Aun puede ayudar si el repo tiene un único package.json claro en la raíz y una sola estrategia de hooks. Es menos fiable cuando los paquetes tienen scripts independientes, políticas de formateo separadas o comandos de test específicos por workspace.

¿Obliga a usar Prettier aunque el repo ya tenga configuración de formato?

No. Las instrucciones de origen indican crear .prettierrc solo si no existe ya una configuración de Prettier. Ese detalle es importante porque facilita la adopción sin romper convenciones existentes.

¿Puedo usar setup-pre-commit para Git Workflows más allá del formateo?

Sí, pero en un sentido limitado. La skill permite añadir typecheck y test al flujo de commit cuando esos scripts ya existen. No es una herramienta completa para diseñar protección de ramas ni CI.

Cómo mejorar la skill setup-pre-commit

Dale a la skill hechos más sólidos sobre el repo desde el principio

La forma más rápida de mejorar setup-pre-commit usage es aportar señales concretas del repo en tu prompt:

• package manager
• si existe typecheck
• si existe test
• si los tests son rápidos
• si ya existe una configuración de Prettier
• si ya existe .husky/

La skill se vuelve mucho más fiable cuando trabaja con hechos verificados en lugar de suposiciones.

Pide una implementación orientada a diff

Un buen prompt de mejora es:

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.

Esto ayuda especialmente en repos que quizá ya contienen tooling parcial.

Evita el fallo más habitual

El fallo más común es añadir comandos que el repo no puede ejecutar. Para mejorar el resultado, indícale explícitamente al agente:

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

Esa instrucción está alineada con la skill de origen y evita commits rotos.

Ajusta la skill setup-pre-commit pensando en la velocidad del equipo, no solo en la corrección

Muchos equipos descubren que npm run test en pre-commit se siente demasiado pesado. Si la velocidad importa, pide al agente que evalúe el coste del 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.

Así la skill deja de ser solo “instalar tooling” y pasa a “encajar en el flujo real de trabajo”.

Pide comandos seguros para tu package manager

Si tu equipo usa pnpm, yarn o bun, dilo explícitamente aunque el lockfile ya esté presente. Eso reduce la ambigüedad y mejora la consistencia de los comandos en los archivos de hooks generados y en las instrucciones posteriores.

Pide al agente que respete los estándares existentes

Si tu repo ya tiene archivos de formato o de hooks, añade:

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

Esto importa más de lo que parece. El tooling de pre-commit suele fallar a nivel de adopción cuando sustituye con demasiada agresividad las convenciones locales.

Mejora la calidad de salida con un paso de validación

Un mejor prompt final incluye:

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.

Esto empuja al agente más allá de crear archivos: lo lleva a comprobar que la configuración sea realmente usable.

Itera después de la primera pasada

Si la primera salida es técnicamente correcta pero poco práctica, afínala con alguno de estos seguimientos:

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

Eso suele ser más eficaz que empezar de cero con un prompt nuevo y demasiado amplio.

Lo que más les importa a los usuarios

Para la mayoría de quienes adoptan esta skill, la mejor setup-pre-commit guide no es “cuántas herramientas instala”, sino si:

• funciona de inmediato con el repo actual,
• evita romper los commits,
• respeta la configuración existente,
• sigue siendo lo bastante rápida como para que el equipo quiera mantenerla activa.

Si usas la skill con esos resultados en mente, es mucho más probable que aporte valor duradero.