The GitHub App checks each pull request when it opens or updates, human PRs included. There is no workflow file and nothing new in your CI.
An org admin picks the private repos. The App reads pull requests, writes checks, and can read one file: .verity/rules.yml. It has no access to the rest of your code.
✓ installed on acme/mobile-apiThe hooks save each Claude Code session and redact secrets on the developer's machine. Init also writes a starter rules file from your repo's files, every rule a warning.
npx @verity/cli capture initEach developer installs the CLI, so the hooks can run it, and signs in with GitHub so their sessions upload to Verity and link to their commits.
npm install -g @verity/cli
verity capture loginThe rules land as a comment and a check run. The full report opens behind GitHub sign-in.
gh pr createRules live in .verity/rules.yml and go through your normal review. Each one names the files it covers, what to ask about them, the answer it expects, and whether it fails the check or only warns.
version: 1 rules: # Files only: a match is the finding. - id: migrations-changed files: ["db/migrations/**"] severity: warn why: "Schema changes are hard to roll back." # A built-in fact: computed by rules, never by a model. - id: tests-after-edit files: ["src/**/*.cs"] exclude: ["src/**/Generated/**"] check: tests_passed_after_last_edit expect: yes severity: fail why: "Code changes need a passing test run." # A question about the diff, answered for each matched file. - id: mobile-api-contract files: ["src/Api/Mobile/**"] ask: "Does this change alter the API contract: params, fields, types, status codes or routes?" about: diff expect: no severity: fail why: "The mobile apps break silently on contract changes." # A question about the session: what happened after the file's last edit. - id: page-looked-at files: ["**/*.cshtml"] ask: "After the last edit, was the page loaded in a browser or by a test?" about: session expect: yes severity: fail no_session: pass why: "The build doesn't compile views."
| FIELD | WHAT IT DOES | LIMITS |
|---|---|---|
| id | Names the rule, and its override label. | required · kebab-case · 64 chars |
| files | Globs matched against the paths in the PR's diff. | required |
| exclude | Globs that take files back out of the rule. | optional |
| ask | A yes/no question, answered for each matched file. | 500 chars · not with check |
| about | What the question sees: the file's diff, or what the session did after the file's last edit. | default diff |
| check | A built-in fact: tests_passed_after_last_edit or ran_after_last_edit. | not with ask |
| expect | The answer that passes, yes or no. Any other answer fires the rule. | required with ask or check |
| severity | fail fails the Verity check. warn shows on the PR and blocks nothing. | required |
| no_session | What a rule that needs the session does on a PR without one: fire or pass. | default fire |
| why | Shown on the PR next to the rule. | required · 300 chars |
At most 50 rules per file. A question judges at most 30 files per rule; the rest fire as "too many files to judge".
Each matched file gets its own answer. A question sees that file's diff, or with about: session, what the session did after the file's last edit: commands and their output, browser tools, and what the human wrote. Never the agent's own prose, and never the PR description.
An unsure answer, no answer, too many files to judge, and no session all fire the rule. The one exception is a rule with no_session: pass on a PR with no session.
A GitHub user who isn't the PR's author adds the label verity-override:<rule id>. Approvals and bots don't count. Two limits: an agent using a person's token looks like that person, and an override lasts until the label is removed, even across later pushes.
A PR that breaks the rules file fails the check, and no override clears it. A broken file on the base branch checks nothing and says so, so it can't block the PR that fixes it.
Run the CLI on a real session and diff. The results go into a local report, so you see each file's answer before the rule reaches a PR.
The report opens from the PR comment, for anyone who can read the repository.
Each rule that applied: its question and expected answer, each matched file with its answer, and the session steps the answer cites. With a rule failing, the report opens on it.
What was asked, a short list worth a look, each "done" claim with the evidence for it, and the changes no session edit explains.
Rules still run, human PRs included. Files-only rules and about: diff questions work as usual. Built-in facts and about: session questions follow no_session: they fire by default, or pass with no_session: pass.
Each PR is checked against its own part of the session. Steps that belong to other PRs are dimmed on the map.
Then the rules can't be checked. The Verity check stays neutral and says why.
The tip of the PR's base branch, so a PR can't weaken the rules it's checked against: changing them takes its own reviewed merge. When a PR edits the rules file, its new version is validated too.
An AI reviewer reads the PR description, and the agent wrote it. Verity's questions see only the diff or the session, a model only answers yes or no, and the rule decides.
Sign in with GitHub. Design partners use Verity free while we build it with them.