Skills

Check TypeScript structural conventions with konsistent

For people validating project-level TypeScript structure patterns; install konsistent-config and validate first, do not batch-fix files on the first try.

Official source · konsistent

Install

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

Who it's for

This fits people whose TypeScript repository already has (or is about to write) project-level structure conventions, and who want a CLI to check whether files and directories follow those patterns. The official repository is https://github.com/vercel-labs/konsistent It says it checks files and directories for whether they match declared structural patterns, filling the gap left when ESLint, Biome, and oxlint only cover in-file style and do not verify project-level structure. Examples include every provider package must export the same shape, or every adapter must extend the base class. It is not another code styler.

It is a better fit for people who write konsistent.json first, then validate / check. If the repository has no structure conventions yet, do not treat the first try as automatically rewriting every file. The material does not name a required agent product.

First try in 3 minutes

The skill’s main path installs the config skill first:

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

Prerequisites: the current environment can run npx, and you are ready to write or inspect konsistent.json in a TypeScript repository. The material writes no Node version. Confirm the directory may receive configuration, then run it; the side effect is installing the konsistent-config skill. After install, let the skill check or draft configuration first; do not batch-change business code.

Low-risk task: in an agent that can already use this skill, only generate or inspect konsistent.json, then run the official check:

konsistent validate

Success signal: the configuration file passes Validate the konsistent.json configuration file, not that a pile of source has already been rewritten. If you do not have the CLI yet, the material’s development-dependency example is npm install konsistent --save-dev; confirm this is a repository you are allowed to write before you run it. Do not run the fix skill in this step.

If the interface asks for a secret that never appears in the material, or wants to run every package-manager install command at once, stop at once.

Use cases

Case 1: Declare and validate structure conventions. This matches the konsistent-config skill and konsistent validate. It fits people who do not yet have a stable konsistent.json and only want the patterns written correctly first. The material does not write a field list for the configuration; what you can confirm is: configuration first, then validate. Do not write case 1 as if the whole repository already passed.

Case 2: Check against the conventions or walk violations one by one. This matches konsistent / konsistent check (Check structural conventions), and the second skill npx skills add vercel-labs/konsistent --skill konsistent-fix-violations. It fits people whose configuration already passed validation and who only want to see which files miss the pattern. check is relatively reversible; fix-violations walks violations and can change files, so confirm the current branch may be modified before you run it. The material does not say automatic repair is always safe.

Limits

It does not replace in-file rules from ESLint, Biome, or oxlint; it only fills project-level structure. The material gives three development-dependency installs — NPM, PNPM, Bun. On the first try pick the one you already use; do not treat all three as required. konsistent is the short form of konsistent check; both need a usable konsistent.json. There is no promise of publishing, formatting, or non-TypeScript repositories. Do not invent an install method that never appears.