Skills

Vérifier les conventions de structure TypeScript avec konsistent

Pour qui valide des motifs de structure TypeScript au niveau projet ; installez d’abord konsistent-config et validate, sans réparer les fichiers en lot au premier essai.

Official source · konsistent

Install

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

À qui ça s’adresse

Cela convient à qui a déjà (ou va écrire) des conventions de structure au niveau projet dans un dépôt TypeScript, et veut une CLI pour vérifier que fichiers et répertoires suivent ces motifs. Le dépôt officiel est https://github.com/vercel-labs/konsistent Il vérifie si files and directories match declared structural patterns, et comble le trou laissé quand ESLint, Biome et oxlint ne couvrent que le style dans le fichier, sans vérifier la structure projet. Exemples : every provider package must export the same shape, ou every adapter must extend the base class. Ce n’est pas un autre outil de style.

Cela convient mieux à qui écrit d’abord konsistent.json, puis validate / check. S’il n’y a pas encore de conventions, ne lisez pas le premier essai comme une réécriture automatique de tous les fichiers. Le matériau ne nomme aucun produit d’agent obligatoire.

Premier essai en 3 minutes

Le chemin principal de la skill installe d’abord la skill de configuration :

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

Prérequis : l’environnement actuel peut exécuter npx, et vous êtes prêt à écrire ou inspecter konsistent.json dans un dépôt TypeScript. Aucune version Node. Confirmez que le répertoire peut recevoir la configuration, puis exécutez ; l’effet de bord est d’installer la skill konsistent-config. Ensuite, laissez la skill vérifier ou rédiger la configuration ; ne changez pas le code métier en lot.

Tâche à faible risque : dans un agent qui peut déjà utiliser cette skill, seulement générer ou inspecter konsistent.json, puis lancer le contrôle officiel :

konsistent validate

Signal de succès : le fichier de configuration passe Validate the konsistent.json configuration file, pas qu’une pile de sources a déjà été réécrite. S’il n’y a pas encore de CLI, l’exemple de dépendance de développement est npm install konsistent --save-dev ; confirmez que vous avez le droit d’écrire dans ce dépôt avant d’exécuter. N’exécutez pas la skill de réparation à cette étape.

Si l’interface demande un secret absent du matériau, ou veut lancer toutes les commandes d’installation de gestionnaires à la fois, arrêtez tout de suite.

Cas d’usage

Cas 1 : déclarer et valider des conventions de structure. Cela correspond à la skill konsistent-config et à konsistent validate. Cela convient à qui n’a pas encore un konsistent.json stable et veut d’abord écrire les motifs correctement. Pas de liste de champs ; on confirme : configuration d’abord, puis validate. N’écrivez pas le cas 1 comme si tout le dépôt avait déjà réussi.

Cas 2 : contrôler selon les conventions ou parcourir les manquements un par un. Cela correspond à konsistent / konsistent check (Check structural conventions), et à la seconde skill npx skills add vercel-labs/konsistent --skill konsistent-fix-violations. Cela convient à qui a déjà validé la configuration et veut seulement voir quels fichiers manquent le motif. check est relativement réversible ; fix-violations walks violations et peut modifier des fichiers — confirmez que la branche courante peut être changée. Le matériau ne dit pas que la réparation automatique est toujours sûre.

Limites d’usage

Cela ne remplace pas les règles dans le fichier d’ESLint, Biome ou oxlint ; cela ne comble que la structure projet. Le matériau donne trois installations de dépendance de développement — NPM, PNPM, Bun. Au premier essai, prenez celle que vous utilisez déjà ; ne les traitez pas comme trois exécutions obligatoires. konsistent est l’abréviation de konsistent check ; les deux exigent un konsistent.json utilisable. Aucune promesse de publication, de formatage ou de dépôt non TypeScript. N’ajoutez aucune méthode d’installation absente.