> For the complete documentation index, see [llms.txt](https://docs.tessl.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tessl.io/codifying-and-enforcing-your-skill-standards/verifiers-overview.md). # Verifiers overview Use verifiers to check committed files against repository-specific invariants that a linter cannot express. {% hint style="info" %} **Takeaway** Use a verifier for a binary, observable fact about committed files when a deterministic check cannot express the standard. {% endhint %} {% hint style="info" %} `tessl change verify` can use **Jev** as its judge: `tessl change verify --model jev` (the default is `openai/gpt-5.6-luna`). Jev returns one pass/fail verdict and a confidence per rule with no written reasoning, so it is cheaper and faster to run than a reasoning judge. As with any judge, a run sends the files it checks to your configured LLM gateway. Jev's availability depends on that gateway's configuration and region, and it is not offered for bring-your-own-model organizations. {% endhint %} 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. {% hint style="success" %} Want a coding agent to set up and tune verifiers with you? Install the `tessl/tessl-verify` plugin with `tessl install tessl/tessl-verify`. Its skill walks an agent through authoring verifier JSON, scoping the `verify` block, and adding a CI gate. {% endhint %} ## 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 | Mechanism | Use it for | Example | | -------------- | --------------------------------------------------------- | ------------------------------------------------ | | Rule | Guidance an agent must follow on every relevant task | Use the shared response helper for API routes | | Skill | A workflow an agent should activate for a specific task | Create and register a new API route | | Linter or test | A fact code can check deterministically | Every route file imports an approved symbol | | Verifier | A binary invariant that needs judgment over code or prose | Every user-facing error explains the next action | 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. In CI, `warn` findings remain advisory and `error` findings exit non-zero, so they can block a pull request. 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](/reference/configuration.md#verify-block). ## Next * [Verify agent changes in CI](/codifying-and-enforcing-your-skill-standards/verify-agent-changes-in-ci.md) - create a verifier, inspect its scope, and add a pull request gate. * [Improving agent code quality](/tutorials/improving-agent-code-quality.md) - find recurring review feedback worth turning into a rule, skill, test, or verifier. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.tessl.io/codifying-and-enforcing-your-skill-standards/verifiers-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.