PR Reviews

What happens when the Scrubby GitHub App reviews a pull request.

How it works

When a pull request is opened or updated on a repository with the Scrubby GitHub App installed:

1. Scrubby creates a check run on the PR showing that a review is in progress.
2. It fetches the changed files and their diffs.
3. It analyzes the changeset as a whole, across all changed files.
4. It analyzes each changed file individually against its segment's conventions.
5. It posts findings as PR comments and inline suggestions.
6. It updates the check run with a summary.

What gets checked

Co-change gaps

Files that historically change together but are missing from this pull request. For example, a model changed without its migration, or an API endpoint changed without its client. See Domain Connections.

Domain crossings

When a PR touches files in more than one domain, Scrubby highlights the crossing. Changes that span domain boundaries often need more careful review.

Convention violations

Each changed file is checked against the conventions learned for its segment. Violations are posted as inline suggestions you can commit directly from the PR.

Review output

• PR comment: a summary of changeset-level findings, such as co-change gaps and domain crossings.
• Inline suggestions: specific code changes posted as GitHub suggestion blocks on the relevant lines.
• Check run: a status check on the PR reflecting the review outcome.

Reviews on a pinned repository

If a repository has an index cutoff date set, every PR review against it uses pre-cutoff context only. Conventions, connection weights, and file history all come from the pinned snapshot. The PR's own diff is always read fresh; only the context informing the review is windowed.