Get started fast.

VerisKit needs Node.js 20 or newer, a git repository, and npm / npx. There is no account, no API key, and no install script.

Run init from the repo root. It detects your stack and writes .veris/config.json. Detection is read-only and never overwrites an existing config.

npx veriskit init

The package is veriskit; the command it installs is veris. To keep veris on your PATH, add it as a dev dependency:

npm install -D veriskit

Then every command runs as veris <command>.

From an initialized repo, prove a change and write the report in two commands.

veris verify
veris report

verify runs every configured check in parallel and prints the verdict. report writes a Markdown summary to .veris/reports/ that you paste straight into the pull request. A clean run reads like this:

VerisKit

Project     veriskit

Checks
  ✓ types          1.2s
  ✓ unit           2.4s
  ✓ lint           0.6s

Result
  ✓ Verified

Commit      4fa33a9 · tree clean

Report
  .veris/reports/verify-20260710-153000.md

veris doctor checks your environment and detected stack if a command behaves unexpectedly, and veris test runs the detected test tool on its own.

VerisKit returns one verdict with three states, not two. A wall of green checkmarks does not tell you whether a change is safe, so VerisKit reads the real exit codes and output of each check and never folds a skipped or unknown result into verified.

Verdict	Exit code	Meaning
verified	0	every configured check ran and passed
failed	1	at least one check failed
partial	2 (0 with --partial-ok)	no failures, but a check was skipped or its result is unknown

A partial verdict is not a pass. It means a check could not run or its result is unknown, for example a tool that is configured but missing, or a suite that reported nothing. Use --partial-ok when you want to accept a partial on purpose; it exits 0 while still labeling the run partial in the output and the report. The exit codes are stable, so a pull request or CI job can gate on them directly.

Running the whole suite on every save is slow enough that people skip it. VerisKit narrows the run to what your change actually reached.

veris affected
veris affected --base main
veris watch

affected runs only the checks, and only the test files, reached by your changes, using an import graph built from the project's own TypeScript. Pass --base <ref> to scope it to a PR or CI diff. watch re-runs the affected checks as files change, with native fs.watch and a --poll fallback.

Narrowing is conservative. When VerisKit cannot prove a smaller set is safe, it runs the full suite, so an affected test is never skipped. affected and watch never report a bare Verified either: a scoped run says so, so you always know whether the verdict covered everything or only the slice you touched.

Coverage percentages hide the risk. VerisKit maps how the code connects, then points at the files that matter and have no tests behind them.

veris scan
veris plan

scan maps the import graph from the project's own TypeScript, with a dependency-free scanner fallback, writes .veris/graph.json, and surfaces untested high-impact files. plan turns that into prioritized recommendations: high-impact untested files, weak verification, and risky changes.

Both are read-only and analysis only. VerisKit recommends what to test; it does not generate tests or edit your code.

Every verify and affected run writes a canonical, git-anchored record, so a verdict is something you can recompute later rather than a line in a log.

veris evidence show
veris evidence bundle
veris evidence verify .veris/evidence/<bundle>.json

Each run writes .veris/runs/<id>/evidence.json (schema veriskit/evidence@1) with a sha256 integrity digest over the whole record and a sha256 of each per-check log. evidence show prints the latest record's key facts. evidence bundle packages the latest run, the record, report, and logs, each digested, into one portable proof file under .veris/evidence/. evidence verify <file> recomputes the digests and checks a record or a bundle.

Be honest about what this proves. An integrity digest detects later edits and corruption. It is not forgery-proof on its own, so publish the digest separately or sign it if you need stronger guarantees. Cryptographic signing is planned.

VerisKit names its edges instead of hiding them. Today it does not:

• Detect framework routes or endpoints. It verifies the checks your project runs, not live HTTP surfaces.
• Generate tests. scan and plan recommend what to test; writing the tests is yours.
• Model monorepos. It works from one project root. Multiple packages under one repo are not modeled yet.
• Fully analyze every project. On plain-JS projects, or TypeScript 7.x native-compiler projects, it uses a dependency-free scanner fallback instead of the full graph.
• Sign evidence cryptographically. The evidence digest detects edits and corruption; it is not a signature yet. Cryptographic signing is planned.

Everything runs locally with two dependencies, cac and picocolors, and Node built-ins.

The full surface, compact.

• init detects the stack and writes .veris/config.json. Read-only detection; never overwrites an existing config.
• doctor checks your environment and the detected stack.
• test runs the detected test tool on its own.
• verify runs every configured check in parallel and returns verified, failed, or partial, with exit codes 0, 1, and 2.
• report writes a Markdown summary of the latest run under .veris/reports/.
• affected runs only the checks and test files reached by your changes. --base <ref> scopes it to a diff.
• watch re-runs affected checks as files change. --poll for filesystems that need it.
• scan maps the import graph and finds untested high-impact files.
• plan recommends what to test from the scan.
• evidence verify | bundle | show recomputes a record, packages a portable proof file, or prints the latest record.

Everything is local and read-mostly. VerisKit runs your configured checks only when you invoke verify, affected, watch, or test.