PR risk review
Is this pull request safe to merge, or does it need a careful human look?
Reads the PR description and diff and decides rather than writes: risky areas touched without tests, breaking changes, leftovers such as debug code and secrets, scope that doesn't match the description, and changes too big to review in one sitting.
Try it live
Real calls to Jev. Pick an example or paste your own.
Pick an example or paste your own input, then run it.
Under the hood
Every question and rule, in the open. Fork it to change any of them.
What it asks
Reads description and diff, then asks 7 questions in one call.
- Q1Touches a risky areaYes / no
Does the
difftouch a risky area: authentication, permissions, payments, database migrations, encryption or infrastructure config? - Q2Has testsYes / no
Does the
diffadd or update tests that cover the change? - Q3Needs testsYes / no
Does the
diffchange behavior that tests should cover? (Typo fixes, copy changes, comments and formatting don't.) - Q4Matches the descriptionYes / no
Does the
diffdo what thedescriptionsays, and nothing unrelated? - Q5Breaking changeYes / no
Could the
diffbreak existing users or callers (a changed API, a removed field, a renamed config, or a changed default)? - Q6LeftoversYes / no
Does the
diffleave debugging code, commented-out code, stray TODOs or secrets? - Q7ScopePick one
How big is the change in scope (not in lines)?
TinySmallMediumLarge
How it decides
Rules run in code, top to bottom. The first one that matches gives the verdict.
- 1If Leftovers ≥ 0.75Changes requested
- 2If Touches a risky area ≥ 0.6 and Has tests < 0.5Changes requested
- 3If Breaking change ≥ 0.7Needs careful reviewreview
- 4If Touches a risky area ≥ 0.6Needs careful reviewreview
- 5If Matches the description < 0.5Needs careful reviewreview
- 6If Scope is LargeNeeds careful reviewreview
- 7If Needs tests ≥ 0.6 and Has tests < 0.4Needs careful reviewreview
- ·DefaultSafe to merge
Call it from your code
Every template runs as-is with an API key, no setup: POST /api/v1/judges/pr-risk-review/run.
curl -X POST https://tryevally.com/api/v1/judges/pr-risk-review/run \ -H "Authorization: Bearer $EVALLY_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "input": { "description": "Small cleanup of the login handler", "diff": "--- a/src/auth/login.ts\n+++ b/src/auth/login.ts\n@@ -12,7 +12,6 @@ export async function login(req) {\n const user = await db.users.find(req.body.email);\n- if (!(await verify(user.hash, req.body.password))) throw new Unauthorized();\n+ console.log('\''login attempt'\'', req.body);\n return issueSession(user);\n }" }}'Seen in the wild
Community builds on Jev that use this pattern. Not affiliated with Evally.
More in Engineering
- Engineering
Semantic code lint
Lint code against conventions written in plain English, the rules a regex can't express.
CleanWarningsViolations5 questions - Engineering
Commit message check
Does the commit message match the staged diff, with no secrets or debug leftovers?
Looks goodAmendBlock5 questions - Engineering
PR labeler
Label pull requests by type and area, and flag what belongs in the changelog.
FeatureBug fixRefactor+64 questions - Engineering
Package risk check
Catch typosquats and hostile install scripts before an install runs them.
AllowReviewBlock7 questions - Engineering
Vulnerable code check
Flag injection, path traversal, hardcoded secrets and other common holes in a change.
CleanReviewVulnerable4 questions - Engineering
Judge question review
Review a question before Jev answers it: two judgments in one, inputs no option fits, a rating hiding in a yes/no.
Good to goImproveRewrite3 questions - Engineering
Should this be a judge?
Paste a prompt from your code. Find out whether it's really a decision a judge would answer faster and cheaper.
Use a judgeSplit itKeep the LLM4 questions