PRGuard

PRGuard for engineers

Feedback in Minutes,
Not Meetings.

The slowest part of shipping isn’t writing the code — it’s waiting for someone to review it.

PRGuard is an automated code review tool: it reads every pull request and push against your team’s written standards and posts a review in minutes — specific findings, on specific lines, with the reasoning spelled out.

It comments — and when it thinks it can fix a finding, it offers the fix. Nothing lands without your approval.

Start the $10 trial See PRGuard run

Retry failed webhook deliveries #482

Open feature/webhook-retries · pushed a few minutes ago

billing/webhooks.py

PRGuard reviewed this line Error

Non-idempotent payment handler

Stripe redelivers events after timeouts, and nothing here records what was already processed, so a retried webhook charges the customer twice.

“Payment webhook handlers must be idempotent.” payments.md

A fix is available on requestFailed · 1 finding

Illustrative example

What You Get on Every Change.

A review that’s there before your coffee is.

Minutes after you push, findings land on the lines they’re about — what’s wrong, why it matters, and which of your team’s standards it breaks.

No waiting for a reviewer’s calendar to clear before you find out.

Human review starts from a triaged first pass instead of a cold diff — the practical way to reduce PR review time without lowering the bar.

Architectural drift, flagged the moment it starts.

The shortcut that bypasses the service layer, the query that belongs in a selector, the pattern your team agreed to retire — caught in the change that introduces it, not in the rewrite six months later.

When you want the fix, ask for it.

Where PRGuard thinks a finding is fixable, it offers an AI-drafted fix — on request, per finding. On a PR audit it lands onto your PR’s own branch for you to review like any other commit.

Nothing is committed on your behalf without your say-so.

What a Finding Looks Like.

Line-level, explained, and tied to a written standard — feedback you can act on without a follow-up meeting.

non-idempotent-handler

Payments

Details

billing/webhooks.py:14

A retried webhook charges the customer twice. Stripe redelivers events after timeouts, and nothing here records what has already been processed.

Non-idempotent payment handler: in handle_webhook(), the charge is written at line 14 without checking ProcessedEvent. Because event.id is never recorded, a redelivered event re-executes the whole charge path — violating your rule that payment webhook handlers must be idempotent.

Copy

Replace the direct charge write in handle_webhook() with a guard: ProcessedEvent.objects.get_or_create(stripe_id=event.id), returning early when the event was already processed.

In billing/webhooks.py, make handle_webhook() idempotent: before any processing, guard with ProcessedEvent.objects.get_or_create(stripe_id=event.id) and return HTTP 200 immediately when the event was already processed. Do not change the charge logic itself.

  def handle_webhook(request):
      event = _verified_event(request)
+     _, created = ProcessedEvent.objects.get_or_create(
+         stripe_id=event.id)
+     if not created:
+         return HttpResponse(status=200)
      charge = _record_charge(event)
      return HttpResponse(status=200)

View rule: payments.md

Unassigned Assign

Illustrative example. Findings are advisory by default — a person approves every fix before it lands.

Not another noisy linter. PRGuard isn’t a catalog of thousands of lint rules. It enforces the standards your team wrote, in plain language, judged semantically on each change, plus a small security floor that always applies. Until you’ve written any, it uses a short baseline of common defect classes, so every finding names the rule it broke.

What Engineers Ask.

Will PRGuard flood my pull requests with nitpicks?

No. Once your team has written its standards, PRGuard enforces those, plus a small security floor that always applies; before then it uses a short baseline of common defect classes.

Every finding names the rule it broke, so if something is noise, the fix is writing or editing a rule, not muting a scanner.

Can PRGuard commit code to my branch without asking?

No. Where PRGuard thinks a finding is fixable it offers an AI-drafted fix, and nothing happens until you request it.

On a PR audit the fix lands on your PR’s own branch as a commit you review and approve like any other.

Do direct pushes get reviewed too, or just pull requests?

Both. Pushes are audited the same way pull requests are, so a commit straight to main gets the same feedback.

Skip markers exist for changes that genuinely don’t need review, but they’re off until your team enables them per repository.

The AI credits are included.

AI usage is part of your subscription, not a bill on the side. Every plan includes a set monthly AI credit allowance, and each audit draws from it — no separate API key to bring, no separate token invoice. And if a busy month needs more, top-up credits are available anytime and roll over.

Start Governing Your Code Today.

Set up in under 5 minutes.

Start the $10 trial

Feedback in Minutes,Not Meetings.