How do you get Proctor reviewing your pull requests?

When is this the right size?

When you want one gate before anything builds. Proctor only checks output: it never changes code, it runs beside the reviewer your team already has, and the worst case is an opinion you disagree with. Engineering orgs that already run their own software factory start here, read Proctor’s findings next to their own for a week, and add the builders when the record earns it.

How do you set it up?

On Create a Team, choose Pull request reviews and pick the repositories from the ones your GitHub App installation covers. A repository another Team already reviews shows as taken, with that Team’s name. Click Create. The Team is named for the repository, Proctor’s line comes on and posts its reviews on its own, and the small print says it: reviews start on the next pull request. Nothing else runs.

What does Proctor post?

One review per pull request, through its checks: deep review, business fit, database, security, tests, and any check you add. It posts the findings and a verdict, then follows up on each new commit until the pull request is clean. The findings it weighed and discarded sit one click behind the review, each with its reason, so a quiet review is worth something. Files under generated directories and lock files are excluded by default.

Every review is also a row on Work in Review, with the same case file as any ticket: what it read, what it found, and what it cost.

What is a check?

A specialist lens inside Proctor’s work, never an Agent of its own. Deep review and business fit are always on. Database, security, and tests toggle on the line. Add a check of your own on the line’s page: a name, what it looks for in plain words, and optionally the paths it applies to. “Anything touching billing gets the pricing rules read” is a check. Each check’s instructions fold behind a link and open inline.

Supervised or autonomous?

Proctor starts autonomous on a new Team: it posts its review on the pull request on its own. On a person’s pull request, a clean review reads “approval advised”, so a person still approves. On a draft the Team opened, an approving verdict marks the pull request ready. Move the line to supervised from the Team page and the verdict waits for the person named on the line to confirm with one click; its track record sits beside the line either way. Merge is a person’s click at either setting.

How does the Team grow?

By adding a line. The Team page offers the lines the Team does not have yet. Add Wright’s plan and build lines and the Team starts carrying tickets through to draft pull requests; add Bailey and it proposes them from a backlog. The repository claim, the checks, and the record all carry over. A review-only Team is a small Team, not a different kind of thing.