Pull Request Summary Builder

How Pull Request Summary Builder works

Press Load model once: your browser downloads Gemma 4 E2B instruction-tuned (web build) (2.0 GB) from this site and keeps it in its cache. Then add your text and press Summarize locally. The model runs on this device using your graphics card, so nothing you enter is sent to a server. Until the model is loaded, or if your device cannot run it, the tool falls back to a simple keyword check and labels the result as the fallback.

Gemma 4 E2B instruction-tuned (web build) is a small open language model from Google. The tool sends it the instruction below plus your two texts, asks for a JSON answer with fixed fields, and shows each field as a card. It runs at temperature 0, so the same input gives the same answer on the same device, though different graphics cards can word it slightly differently.

Inputs longer than 6,000 characters are cut to that length before they reach the model, and the result says so. The model only sees what you paste: it does not look anything up.

The instruction the model gets

You write a pull request description from the changes and context the user pastes. Describe only changes that appear in the input; never invent files, tests, tickets or behaviour. Use the context to decide what reviewers care about and answer what it asks for when the changes allow it; when they don't, list it as missing.

What it returns

• PR title: A short title in the imperative mood, under 70 characters.
• Summary: Two or three sentences on what changed and why.
• Changes: The main changes, one per line, naming files or components as written.
• Risks and rollback: Risks, customer-visible behaviour and rollback notes that the input supports.
• Missing before review: Things the context asks for that the changes do not show (tests, rollback plan, screenshots and so on).

Worked example

The model's output for the built-in sample, recorded on a desktop browser. Your run may word things slightly differently.

Validate Stripe webhook signatures before parsing (webhooks/stripe.ts) Move invoice retries to a queue with exponential backoff (billing/retryQueue.ts) Ignore duplicate Stripe events by event id Add integration tests for duplicate and unsigned events Reviewer asks: call out risk around retry timing, customer-visible behaviour, test coverage and rollback steps.

PR title

Improve Stripe Webhook Handling with Signature Validation and Retries

Summary

This PR introduces validation of Stripe webhook signatures before parsing events to enhance security. It also moves invoice retries to a queue with exponential backoff for more robust handling of transient errors. New integration tests are added to cover duplicate and unsigned events.

Changes

Validate Stripe webhook signatures before parsing (webhooks/stripe.ts) Move invoice retries to a queue with exponential backoff (billing/retryQueue.ts) Ignore duplicate Stripe events by event id Add integration tests for duplicate and unsigned events

Risks and rollback

Changes to retry timing might affect the latency of invoice processing. Customer-visible behavior is not directly impacted by these internal changes. Potential for unexpected behavior if signature validation fails or retry logic is flawed. Rollback plan should address the changes in retry queue implementation.

Missing before review

Specific details on the exponential backoff configuration. Test coverage details beyond the addition of integration tests. Detailed rollback steps for the retry queue changes.

The model

The files are served from this site, versioned so a cached copy is never stale. Nothing is fetched from a third party while you use the tool.

Limitations

• Small language models make mistakes: they can miss an item, merge two, or state something more confidently than the text supports. Check the result against your input before you rely on it.
• It needs WebGPU and about 8 GB of memory, so it is offered on desktops and laptops, not on phones and tablets. Devices that cannot run it get the keyword fallback, clearly labelled.
• Results describe the input you gave, not the real-world situation behind it. Review them yourself before acting.

Good uses

• Triage developer workflow notes before deeper review
• Prepare consistent labels for repeat workflows
• Reduce manual sorting on small batches
• Keep sensitive drafts in the browser preview