VerisKit

Features

What it does well.

New in 0.6.0

Let the agent verify its own work.

Wire veriskit-mcp into an MCP-aware client and your coding agent runs the same checks you run, then reads back the same honest verdict as tool calls. It verifies its own change against your real tooling instead of reporting that the work is done. Seven tools, five of them read-only, and the verdict still comes from your tools' exit codes.

Seven tools

veris_doctor, veris_scan, veris_plan, veris_log, and veris_evidence_verify read only. veris_verify and veris_affected run the project's own test tooling. Each returns a structured, honest verdict, so a partial still reads as a partial to the agent.

Wire it into a client

Point any MCP-aware client at the package and the tools appear. Nothing to install first, and no key. { "mcpServers": { "veriskit": { "command": "npx", "args": ["-y", "veriskit-mcp"] } } }

The CLI stays light

veriskit keeps its two runtime dependencies. The official MCP SDK lives only in the separate veriskit-mcp package, so wiring up an agent never grows the CLI you install in CI.

Also a library

0.6.0 exposes a programmatic API: verifyProject, affectedProject, and the core detect, graph, history, and evidence functions, for building the verdict into your own tooling.

Where it sits in the family

AgentLoopKit decides what the agent should do next and AgentFlight records what it did. VerisKit answers whether you can trust the result, and now the agent can ask it directly rather than wait for a human to run the suite.

Publish

Put the verdict where reviewers look.

Pass --github and VerisKit posts the verdict to the pull request itself, as one sticky comment and a Check Run, where the reviewer already is rather than in your terminal. Publishing is a side channel: it reports the verdict and never changes it.

veris verify --github

Posts and updates one sticky PR comment carrying the verdict and report, and creates a GitHub Check Run whose conclusion follows the verdict: verified passes, failed fails, partial is neutral. Re-runs edit the same comment, so a busy PR gets no comment spam.

Your token, your environment

VerisKit reads GITHUB_TOKEN from the environment and never stores it. The workflow needs pull-requests: write and checks: write. Since 0.5.1 a failed publish carries GitHub's own message, for example "Resource not accessible by integration" when those permissions are missing, and the token never appears in an error.

It cannot rescue a bad run

A missing token or a run outside a PR prints a notice, and the exit code still reflects the verdict. VerisKit reports a GitHub API error and then ignores it. A publish can fail without turning a failed run green.

veris badge

Writes a shields.io endpoint JSON so a README badge shows the last verdict. The GitHub API calls go over Node's built-in fetch, so none of this adds a dependency.

Evidence

An evidence trail you can recompute, and sign.

Every verify and affected run writes a canonical, git-anchored evidence.json, and the evidence command recomputes it, bundles it, prints it, or signs it. The verdict stays honest, and now it carries a digest and, if you want, a signature.

Git-anchored evidence.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. It replaces the older metadata.json, and no new runtime dependency comes with it.

veris evidence verify, bundle, show

evidence verify <file> recomputes and checks a record or bundle, evidence bundle packages the latest run (record, report, and logs, each digested) into one portable proof file under .veris/evidence/, and evidence show prints the record's key facts.

Signing, since 0.4.1

evidence keygen creates an Ed25519 keypair with Node's built-in crypto, and evidence sign <evidence.json> writes a detached signature over the record's integrity digest. evidence verify picks up a sibling signature on its own, and bundles carry it. Signing is opt-in, unsigned evidence still verifies for integrity, and VERISKIT_SIGNING_KEY supplies the key in CI.

What it proves, and what it does not

A digest detects later edits and corruption. A signature proves that a key vouched for the record, not who holds that key, unless you assert the expected signer with --pubkey or --key-id. VerisKit says so plainly rather than overselling the proof. Keyless signing through sigstore is still planned.

Commit and tree state, on the record

The report and terminal show the git commit and whether the working tree was clean, and the report carries the evidence digest, so a verdict is tied to an exact point in history.

The verdict

One honest verdict, three states.

A green wall of checkmarks does not tell you whether a change is safe. veris verify runs the configured checks in parallel, reads their real exit codes and output, and returns one verdict. There are three states, not two, and a partial is never a pass.

verified (exit 0)

Every configured check ran and passed. This is the only state that means the change cleared the bar you set.

failed (exit 1)

At least one check failed. VerisKit shows which one and preserves its output, so you fix the cause rather than hunt for it.

partial (exit 2, or 0 with --partial-ok)

No check failed, but one was skipped or its result is unknown. A partial verdict is not a pass. VerisKit never folds a skipped check into verified, and --partial-ok lets you accept a partial on purpose, in the open.

A report you can paste

veris report writes a Markdown summary, the verdict, each check with timing, and the git commit and tree state, so the evidence goes straight into the pull request.

Browser tests, when you ask

veris verify --browser runs your Playwright suite and folds it into the same verdict (a browser entry in .veris/config.json does the same). It is opt-in, so a normal verify stays fast, and veris doctor lists browser as an available capability once it detects Playwright. If VerisKit cannot parse the results, it reports the check as unknown rather than claiming it passed.

Developer loop

Re-run only what your change reached.

A full suite on every keystroke is slow enough to skip. VerisKit narrows the run to the checks and test files your changes actually reach, built from an import graph, and keeps it honest with a conservative fallback.

veris affected

Runs only the checks, and only the test files, reached by your changes, using an import graph from the project's own TypeScript. Pass --base <ref> to scope it to a PR or CI diff.

veris watch

Re-runs the affected checks as files change, with native fs.watch and a --poll fallback for editors and filesystems that need it.

Never a false-fast run

Narrowing is conservative: when VerisKit cannot prove a smaller set is safe, it runs the full suite. An affected test is never skipped, and affected or watch never report a bare Verified.

veris log

Every run leaves an evidence record, so VerisKit can show the trend. veris log lists past runs newest first with the verdict, checks, and commit, and veris log --flaky names the checks that both passed and failed across recent runs. History is local to the machine: .veris/runs is gitignored.

Project intelligence

Find the untested code that matters.

Coverage percentages hide the risk. VerisKit maps how the code connects, then points at the high-impact files with no tests behind them. It reads and recommends; it never writes code.

veris 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.

veris plan

Turns the scan into prioritized recommendations: high-impact untested files, weak verification, and risky changes. Analysis only, no code generation.

Trust

Local, light, and honest.

VerisKit runs the checks you already run and writes local files. Nothing uploads, nothing phones home, and the dependency list is short enough to read.

Two dependencies

The veriskit CLI ships with exactly cac and picocolors. Everything else is Node built-ins, including the crypto behind evidence signing and the fetch behind GitHub publishing, so it installs light and stays auditable. The MCP SDK lives only in veriskit-mcp.

Nothing leaves the machine, unless you ask

No cloud, no telemetry, no source upload, no account, and no LLM calls. VerisKit reads your tools' output and writes under .veris/. The one outbound path is --github, which you opt into, which talks only to the GitHub API, and which posts the verdict and report you already have.

What it does not do yet

No framework route or endpoint detection, no test generation, one project root (monorepos are not modeled yet), a scanner fallback on plain-JS or TS 7.x-native projects, and no keyless signing. VerisKit names its edges rather than hiding them.