SELF-HOSTED  •  GITHUB-NATIVE

Route every pull request
to the right reviewer.

TriagePilot provides self-hosted, risk-based pull-request routing for GitHub. It scores change risk, matches code ownership, and checks reviewer availability to choose who to ask for review.

Runs in your infrastructureShadow mode firstEvery decision is auditable

DETERMINISTIC BY DESIGN

From webhook to the right reviewer

Risk scoring determines the review tier. Ownership and availability determine who is eligible. A separate human-review policy checks the approval count; GitHub merge requirements decide whether that check blocks merging.

01

Ingest

GitHub events arrive with the full pull request context.

02

Score + match

Risk signals and changed paths meet repository ownership policy.

03

Route + record

Available reviewers are selected and every outcome is logged.

SELF-HOSTED CONTROL

Your review policy, running on your infrastructure.

TriagePilot keeps routing deterministic, repository policy file-managed, and operational state close to the teams who own it.

FAIR SOURCEUse, modify, and self-host for your organization — with an Apache 2.0 future license.

Risk-based routing

Score change size and repository signals so high-risk pull requests get the attention they deserve.

Availability-aware cohorts

Central schedules keep absent reviewers out of new and outstanding review cohorts.

Safe shadow mode

Evaluate routing decisions before TriagePilot makes any writes back to GitHub.

Auditable recovery

Inspect every decision and securely re-run routing from current GitHub state when events are missed.

REVIEW POLICY · V1.1.1

How risk-based review works

Start with the risk-based pull-request review guide, or compare options in the GitHub reviewer-assignment guide.

How do I configure risk?

Set thresholds, sensitive path weights, size limits, and documentation suppressors in .triagepilot.yml. TriagePilot reads policy from the trusted base revision, never the unmerged pull-request head.

How many reviewers are requested?

Low risk requests no human reviewer and receives a policy approval in enforce mode. Medium risk requests one. High risk requests one by default, or two with routing.high_risk_reviewers: 2. Matching owners come first; eligible fallback reviewers fill remaining slots. The author is excluded, and shortfalls are recorded.

Can I evaluate without GitHub writes?

Yes. With mode: shadow, TriagePilot reads GitHub data and records decisions locally. It sends no reviewer requests and writes no labels or checks. Availability schedules are administered centrally, outside repository YAML, and narrow the eligible pool.

Does requesting reviewers block merging?

Reviewer selection and approval enforcement are separate. In enforce mode, configure triagepilot/human-review-policy as a required check in a GitHub ruleset to enforce the risk-dependent approval count. Active individual approvals count even from people who were not selected. Existing GitHub requirements still apply.

Does TriagePilot use CODEOWNERS?

Its ownership rules are separate from CODEOWNERS; it does not import that file. You can keep GitHub’s owner-review requirements alongside TriagePilot, but maintain both policies. TriagePilot accepts individual GitHub handles, not organization team handles.

What is the license?

TriagePilot is Fair Source/source-available under FSL-1.1-Apache-2.0. Internal use, modification, and self-hosting are permitted subject to the license. Competing commercial use is restricted; each version receives an Apache 2.0 future license after two years.

Details: v1.1.1 repository configuration · human-review policy.

PUBLIC IMAGE · DOCKER COMPOSE

Run TriagePilot where your code lives.

One image runs the web and worker services in separate containers. PostgreSQL stays separate, and one deployment manages one GitHub organization.

docker pull ghcr.io/triagepilot/triage-pilot:1.1.1
v1.1.1linux/amd64linux/arm64
DEPLOYMENThealthy
GitHub organization
Selected repositories · webhook events
webAdmin + API
workerExactly one
postgresDurable state

Put every pull request on the right path.

Start in shadow mode, validate the decisions, then enable routing with confidence.