Full repo vs Diff Audits

Full-repo vs. Diff Audits

16 Eyes ships two commands built on the exact same engine — same persisted lenses, same verify → adversarial-review → synthesis pipeline, same guards — that differ only in scope.

/16-eyes audit — the whole repository

Runs every persisted lens across the entire codebase, regardless of what changed recently. This is the only way to catch a vulnerability that's been sitting untouched in the code for months: no diff-scoped tool, audit-diff included, will ever see it, because nothing in a recent diff points to it.

It's read-only, can take a few minutes (dozens of subagent calls across all lenses), and is meant as a deliberate, occasional deep sweep — not something you run on every commit. A reasonable cadence is a scheduled (e.g. weekly) CI job; see the optional nightly-full-audit template shipped under skills/16-eyes/assets/ci/.

/16-eyes audit-diff — a diff or PR

Runs the same lenses, but each one investigates only the changed hunks of a diff. Built specifically to be cheap enough to run on every PR.

How the diff scope is determined

In order:

1. An explicit base ref/branch or PR number named in the invocation.
2. The GITHUB_BASE_REF environment variable, if set (present in a GitHub Actions pull_request job).
3. The repo's detected default branch (via git symbolic-ref refs/remotes/origin/HEAD, falling back to main then master if that symref is missing — common on a shallow/fresh clone).
4. The merge-base of that branch and HEAD — not the branch tip — so the diff is exactly what the PR introduces, not everything the base branch has gained since the PR started.

If a PR number is known and gh is available, gh pr diff <n> and gh pr view <n> --json number,title,url are used directly — this works even without that PR's branch checked out locally, the normal case in CI.

Size guard

Large diffs (rule of thumb: over ~2000 changed lines, or files that look like lockfiles/minified/vendored/generated output) get trimmed before being sent to lenses. This is never silent — the run's summary states which files were dropped and why, so a report never implicitly claims full coverage of a diff it actually trimmed.

What it never does

audit-diff never designs its own lenses — it has no whole-repo context to profile from a diff alone. It always reuses whatever /16-eyes init (interactive, or auto-bootstrapped the first time audit/audit-diff ran without one) already produced. Empty results per lens are the expected common case: most lenses' focus areas won't intersect most diffs, and each one is asked to return an empty finding list rather than force a match.

Which one to run where

	/16-eyes audit	/16-eyes audit-diff
Scope	Whole repository	Diff / PR only
Cost	Dozens of subagent calls, minutes	Much cheaper — scales with diff size
Best fit	Occasional deep sweep (e.g. weekly/nightly CI)	Every PR, wired into CI as a required or comment-only check
Finds pre-existing, untouched-in-months issues	Yes	No — by design, out of scope
Designs lenses if missing	Yes (auto-bootstrap)	No — always reuses init's persisted set

See docs/ci.md in the repo for the actual CI setup (the published kigiela/16-eyes@v1 Action, the ci.failOn config knob, and the raw-workflow alternative).