Comprueba convenciones de estructura TypeScript con konsistent

Para quién

Encaja con quien ya tiene (o va a escribir) convenciones de estructura a nivel de proyecto en un repositorio TypeScript, y quiere una CLI para comprobar si archivos y directorios siguen esos patrones. El repositorio oficial es https://github.com/vercel-labs/konsistent Dice que comprueba si files and directories match declared structural patterns, y cubre el hueco cuando ESLint, Biome y oxlint solo cubren el estilo dentro del archivo y no verifican la estructura de proyecto. Ejemplos: every provider package must export the same shape, o every adapter must extend the base class. No es otro estilizador de código.

Encaja mejor con quien escribe primero konsistent.json y luego validate / check. Si el repositorio aún no tiene convenciones, no leas el primer intento como reescribir automáticamente todos los archivos. El material no nombra un producto de agente obligatorio.

Primer intento en 3 minutos

La ruta principal de la skill instala primero la skill de configuración:

npx skills add vercel-labs/konsistent --skill konsistent-config

Requisitos previos: el entorno actual puede ejecutar npx y estás listo para escribir o inspeccionar konsistent.json en un repositorio TypeScript. El material no escribe versión de Node. Confirma que el directorio puede recibir configuración y luego ejecuta; el efecto secundario es instalar la skill konsistent-config. Después, deja que la skill contraste o redacte la configuración; no cambies el código de negocio en lote.

Tarea de bajo riesgo: en un agente que ya puede usar esta skill, solo genera o inspecciona konsistent.json y luego ejecuta la comprobación oficial:

konsistent validate

Señal de éxito: el archivo de configuración pasa Validate the konsistent.json configuration file, no que ya se haya reescrito un montón de código. Si aún no hay CLI, el ejemplo de dependencia de desarrollo es npm install konsistent --save-dev; confirma que puedes escribir en ese repositorio antes de ejecutar. No ejecutes la skill de reparación en este paso.

Si la interfaz pide un secreto que no aparece en el material, o quiere lanzar todos los comandos de instalación de gestores a la vez, para de inmediato.

Casos de uso

Caso 1: declarar y validar convenciones de estructura. Corresponde a la skill konsistent-config y a konsistent validate. Encaja con quien aún no tiene un konsistent.json estable y solo quiere escribir bien los patrones. No hay lista de campos; lo confirmable es: primero configuración, luego validate. No escribas el caso 1 como si todo el repositorio ya hubiera pasado.

Caso 2: comprobar según las convenciones o ver incumplimientos uno a uno. Corresponde a konsistent / konsistent check (Check structural conventions) y a la segunda skill npx skills add vercel-labs/konsistent --skill konsistent-fix-violations. Encaja con quien ya validó la configuración y solo quiere ver qué archivos no encajan. check es relativamente reversible; fix-violations walks violations y puede cambiar archivos: confirma antes que la rama actual admite cambios. El material no dice que la reparación automática sea siempre segura.

Límites de uso

No sustituye las reglas dentro del archivo de ESLint, Biome u oxlint; solo cubre estructura de proyecto. El material da tres formas de dependencia de desarrollo — NPM, PNPM, Bun. En el primer intento elige la que ya usas; no las trates como tres ejecuciones obligatorias. konsistent es la forma corta de konsistent check; ambas necesitan un konsistent.json usable. No hay promesa de publicación, formateo ni repositorios que no sean TypeScript. No completes un método de instalación que no aparece.