Outputs

The PR Comment

What every section of the comment means, why we chose this format, and how to read it as a developer.

Anatomy of the comment

Every PR analysis posts a single comment on the pull request. The comment has five parts, always in this order:

  1. Header — emoji + risk level + bold title
  2. Summary line — one-sentence verdict (you should be able to read this and only this and know whether to merge)
  3. Findings table — one row per issue, summarized
  4. Finding details — each finding expanded in 4-section format
  5. Footer — risk score, confidence, time taken, credits used

Risk levels

The header emoji and color directly map to one of six risk levels:

LevelScoreMeans
🟢 SAFE0–9Merge with confidence.
🟢 LOW10–29Minor observations. Probably fine.
🟡 MEDIUM30–49Review recommended before merging.
🟠 HIGH50–79Significant risks. Don't merge without addressing.
🔴 CRITICAL80–100Do not merge. Production-breaking risk.
🟣 NEEDS REVIEWPRMergeSafe is uncertain. Ask a human.

The threshold between "merge button shows green" and "merge button shows red" is configurable per team — see Dashboard → Risk threshold.

The 4-section finding format

Every individual finding follows the same 4-section structure. We enforce this format because feedback that's easy to act on gets acted on; feedback that's vague gets ignored.

WHAT YOU CHANGED

A plain-language description of what the diff did. No jargon. Written so a developer with one year of experience understands without looking anything up.

Example: "You removed the verifyJwt(token) call from the requireAuth middleware in src/auth.ts."

WHY THIS COULD BREAK

The specific consequence. What fails, when, and why. Not a generic "this might cause issues" — concrete.

Example: "Any request with any value in the Authorization header will now pass through as authenticated. src/api/users.tsuses requireAuth for the user-profile endpoint, so unauthenticated users can read any profile after merge."

WHERE TO LOOK

Exact file paths and line numbers. No vague pointers.

WHAT TO DO

A concrete fix. Often includes a code snippet showing what the change should look like.

What about the footer?

The footer line at the bottom of every comment shows:

  • Risk score — the 0–100 number that maps to the risk level above
  • Confidence — how certain the model is. Low confidence (under 70%) triggers NEEDS_HUMAN_REVIEW.
  • Analysis time — how long this PR took to analyze
  • Credits used — how many of your monthly credits this PR consumed (see Credits)

Why this format

Most AI review tools generate noise: style nits, "consider using" suggestions, naming preferences. PRMergeSafe is opinionated. We only flag things that actually break production. The 4-section format forces every finding to be actionable — if a finding can't fill in all 4 sections, it usually isn't worth flagging.