Run the check in CI

By Ohad Krispin, founder of VibeRaven · LinkedIn

`check` exits 1 when it finds a blocker, so it works as a CI step as it is. Add `--base` to report only what a pull request introduced, or `--format sarif` to show findings in GitHub code scanning.

npx -y viberaven@1.7.8 init --github --dry-run

Previews a GitHub Actions workflow that checks every pull request. Or ask your coding agent to "add the viberaven check to CI".

Fail a step on blockers

check exits 1 when it finds at least one blocker and 0 when it finds none, so any CI system can run it as a step. Warnings do not change the exit code.

- run: npx -y viberaven@1.7.8 check

Pin the version in CI, so a new release cannot change a result on its own.

Only what a pull request introduced

--base <ref> compares the checkout with a git ref and splits the findings into new in this change and already there before. It exits 1 only when the change adds a blocker.

npx -y viberaven@1.7.8 check --base origin/main

Compared with HEAD~1 (f9b239b)

New in this change:
  🔴 No RLS policy proof in migrations  (rls_disabled)  new: public.invoices
  ...
Already there before: 21

Verdict: ❌ 2 new blockers in this change · score 5

The ref must exist in the checkout. In GitHub Actions, check out with fetch-depth: 0. A missing ref exits 2 with ERROR: Could not find "<ref>" in this repository.

Comment on the pull request

Add --markdown to print the result as a Markdown table, ready to post as a pull request comment. With --base, findings that were already there fold into a <details> block.

npx -y viberaven@1.7.8 check --base origin/main --markdown > viberaven.md

GitHub code scanning

--format sarif prints SARIF 2.1.0. Each finding id is a rule, with its guide link and the test to run after the fix. Blockers are level error.

npx -y viberaven@1.7.8 check --format sarif > viberaven.sarif

It exits 1 on blockers too, so let the upload step run even when the check step fails. Upload the file with GitHub's SARIF upload action, and the findings show in the Security tab and on the changed lines.

Generate a workflow

npx -y viberaven@1.7.8 init --github --dry-run

It writes two workflows. Review both before you commit them.

.github/workflows/viberaven.yml: Runs on every pull request with a read-only token. It installs the pinned @viberaven/cli@1.7.8 outside the repository with --ignore-scripts, checks the exact head commit and uploads the report.
.github/workflows/viberaven-comment.yml: Runs from the default branch after the first one finishes. It does not trust that artifact: it checks the pull request commits again, then posts the feedback. Only this job can write to pull requests.

Exit codes

Exit codes in viberaven 1.7.8
Command	0	1	2
`check`	No blockers	At least one blocker, a missing folder or an unknown `--format`	The scan failed
`check --base <ref>`	No new blockers	The change adds a blocker	The ref was not found
`changes --strict`	Nothing affected	A provider change affects the repo
`--strict`	`gate.status` is `clear` or `warning`	`gate.status` is `not_clear`	`gate.status` is `error`
`--strict=warning`	`gate.status` is `clear`	`gate.status` is `warning` or `not_clear`	`gate.status` is `error`

--strict runs the older full scan with no command, and writes gate.status to .viberaven/gate-result.json. Write --strict=warning with =. For most CI, check is enough; --strict after check has no effect.

Checked

Checked on November 3, 2026, against the published viberaven 1.7.8, with a real run on a small Next.js + Supabase + Stripe fixture repo.