#Verifiers overview

A verifier is an LLM-as-judge check that compares committed files with an invariant stored as JSON. For example, a verifier can check that every user-facing error includes a next step or that every FastAPI route uses your typed response helpers.

Verifiers belong in your repository. A verifier file describes what to judge, while the verify block in tessl.json selects the files it covers and sets the severity of its findings. This separation lets teams reuse the same verifier with different scopes and enforcement levels.

#When to use a verifier

Use a verifier when all of these are true:

• The standard has a pass or fail answer.
• The evidence is visible in committed files or a diff.
• A reviewer can apply the standard consistently from the supplied context.
• A deterministic tool cannot check it reliably.

Do not use a verifier for subjective preferences such as whether code is elegant. Narrow the invariant until its checklist has observable evidence.

#Choose the right mechanism

Prefer a linter or test when one can enforce the invariant. A rule or skill guides an agent before and during a change; a verifier checks the result after the change. You can pair them: a rule teaches the expected pattern, and a verifier catches changes that do not follow it.

Verifiers are separate from Tessl Code Review. Code Review looks for general problems across a pull request. Verifiers enforce the specific invariants your repository names and configures.

#How verification works

Each verifier JSON file contains the instruction, applicability criteria, evaluation scope, and a checklist of binary rules. The repository's tessl.json groups verifier files, targets source files with include and exclude globs, and assigns an info, warn, or error level.

tessl change verify resolves the configured scope and judges applicable targets. On a pull request, warn findings remain advisory and error findings fail the check, so they can block the pull request. Run it on pull requests by turning on Verify PRs in the Tessl Reviewer GitHub App, or from a workflow you own.

By default, tessl change verify is change-aware: it checks the files a change touches against every applicable verifier, and re-checks a changed verifier or tessl.json rule against its full configured scope. Run tessl change verify --all to audit every file in the current project's configured scopes (include and exclude filters still apply); add --recursive to include linked child manifests in a monorepo.

For the complete configuration fields, see the verify block reference.

#Generate and review verifiers in the web UI

The app can propose verifiers from context you already have, so you don't have to write each one by hand. A generated verifier is a candidate. It isn't part of your repository's policy until you add it, review it, and commit it.

#Generate candidates

1. Sign in and open a skill or other context your organization owns, then open its Conformance view. Only members of the owning organization see this view, so a public skill from another organization has none.
2. Select Generate verifiers.

Each rule in the context that can be checked against files in your repository becomes a candidate verifier. Guidance about process, intent, or judgment can't be checked that way, so context made only of that produces no candidates.

#Inspect a candidate

Before you keep a candidate, read its instruction, applicability, and checklist to confirm it judges what you care about, in the files you expect.

Some rules are better enforced by a deterministic tool. When a candidate is likely to be lintable, use Create lint rule to hand the work to an agent, and keep verifiers for what a linter can't express. See Choose the right mechanism.

#Run a check

Run check checks a repository against one verifier, once. It doesn't set up recurring checks.

A check runs against the repository the context comes from or, for a published plugin, a Project where the plugin is installed. Checks support GitHub repositories only, and run for the organization that owns the context.

The result lists each violation with its file and evidence. A check only speaks for the files it covered: one that failed, or covered only some of the matching files, isn't a clean result. When the app offers Scan more or Retry N failed files, use them to cover the rest.

#Add checks to your repository

1. Select Add to repository.
2. Choose the checks to keep. Checks marked "A lint rule may also cover this check" are good candidates for Create lint rule instead.
3. Select Continue with N verifiers.
4. Copy the prompt into your coding agent, or open it from the dialog.

The app doesn't install, commit, or configure anything itself. Your agent adds the verifier definitions and proposes their scope in tessl.json. You review the changes and commit them. Adding a verifier also doesn't turn on CI. To calibrate severity and run it on pull requests, start it at warn and follow Verify agent changes in CI from step 3.

#Inspect your project's verifiers

Once you've added some verifiers to your project, open Projects, select the project, and open its Verifiers view. See Project verifiers. From a verifier you can:

• Switch between Preview and JSON, and view the source.
• Open Configuration to see where it applies.
• Choose which configuration to look at when the verifier is used more than once. Each use can have its own scope and severity.

Use Run check to check the project against it once, and read the result as described in Run a check.

#Next

• Verify agent changes in CI - create a verifier, inspect its scope, and run it on pull requests with the GitHub App or your own workflow.
• Improving agent code quality - find recurring review feedback worth turning into a rule, skill, test, or verifier.