This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.
What I Built
A review can ask for a screenshot in one place, describe a bug in another, and receive an author reply several days later. A PR status compresses that conversation into a label. The small chore I wanted to address was finding the original ask again and reading it beside the relevant reply.
ReviewRadar is a local evidence workbench for selected public PRs you authored. Gemma identifies individual human-reviewer requests and proposes relevant later author responses. The app places those original passages beside each other, with their dates and GitHub links. You inspect the context, keep a local note, and decide what deserves another look.
It is for the contributor returning to several review conversations after a break: not “write my reply,” but “show me the ask and the context I need before I reply.” The intended saving is repeated searching and rereading. Whether the model's preparation and correction cost makes that worthwhile still needs a genuine-user test.
The input came from my actual open-source contribution history. For example, an Eventyay review requested screenshots or a video. A later author update reported adding screenshots. That pair is more useful to read together than as two disconnected notifications. It still does not establish that the screenshots were sufficient or that a maintainer was satisfied.
There are three separate states throughout the interface:
- What GitHub reported when the snapshot was fetched: PR/review/thread state.
- What the model suggests: a request and a possible conversational response.
- What I decided locally: reviewed, reopened, or a note for later inspection.
No button comments on GitHub, resolves a thread or marks code correct. That boundary keeps a reading aid from quietly becoming an authority over someone else's review.
Demo
Explore the public historical replay.
It shows three real request/response examples in the same workbench used by the local app. The replay has a persistent capture date and incomplete-coverage warning: it deliberately includes only six selected source bodies, with links to the complete discussions. Its analysis was generated by an actual local API run and saved; opening the page does not run a model or import your GitHub account. Review choices in the replay stay in that browser and can be reset.
Try one concrete task in the replay:
- Open the Eventyay screenshots request. Read the reviewer’s exact words beside the author’s later report.
- Expand the original comments or follow the source links. The model has not inspected the screenshots or established maintainer satisfaction.
- Write a next-action note, such as “Inspect the attached screenshots against the requested behavior before following up.” Save it and download the review sheet with the sources attached. Mark it reviewed locally only after your own inspection; reopen it to reverse that choice.
These are historical, possibly-responded examples, not a claim that these PRs currently need another comment. The output is a small source-linked reading plan you can return to after a break.
For live import and inference, use the local setup instructions. The model service runs on loopback. A chronology baseline and source reading remain available without downloading weights.
That installation is a real tradeoff: the pinned model artifact is about 2.84 GB, in addition to the runtime and application dependencies. The public replay lets someone inspect the output before choosing that download. It is not a hosted replacement for the local engine.
Code
Source code and setup: YashAnand69/reviewradar
The repository includes the application, model manifest, audited planning documents, tests, evaluation/error report and a short contributor trial guide. Application code is MIT licensed. Model/runtime dependencies and attributed third-party discussion text have their own rights and notices; the software license does not relicense other people's comments.
How I Built It
The browser is React and TypeScript. A local FastAPI backend imports public authored-PR discussions through the GitHub CLI, validates immutable source snapshots and stores analyses and local decisions in SQLite. Gemma 4 E2B runs through a pinned llama.cpp service. No GitHub credential is sent to the browser, and no hosted inference API is involved.
The first model prototype failed in an instructive way. It treated an author update, approval text and an empty review as requests. Another version altered punctuation while trying to quote a source. Valid-looking JSON was clearly not enough.
I changed the model's job. The application now builds exact source passages with stable keys. The model selects those keys; the server supplies the original text. The pipeline separates request extraction from response matching. Each request's response choices are restricted to existing, strictly later author passages, plus an explicit no-response option. Both stages check the actual runtime context budget before generation.
The chronology baseline provides a deterministic human-comment list in time order. In that view, the contributor finds an ask and searches later author updates themselves. Gemma contributes the semantic step: separating an individual ask from the rest of a comment and considering which later author passage addresses it. The resulting card puts those two passages together. That relationship is a proposal to inspect, not something the baseline or a PR status label establishes; the original discussion is still available when the pairing is wrong or insufficient.
This prevents invented quotations and mechanically impossible source references. It does not prevent every wrong interpretation, so the original comment, surrounding chronology and uncertainty remain available. Oversized input, invalid output or a failed PR cannot quietly become an empty “all clear” queue. Switching to the no-model baseline is an explicit choice.
A saved example makes the limit concrete: one model rationale says the reported screenshots fulfill the request. The source supports only that the author reported adding them. I retained that historical output and placed an explicit unverified-interpretation warning beside it, rather than silently rewriting a successful-looking demonstration.
The interface follows that same principle: evidence first, explanation second. It has reversible local decisions, notes, source filters, source JSON and Markdown export. The corrected compact workbench was checked in the browser at desktop size and at 320 px, with no page-level horizontal overflow observed in those views. Closing saved history with Escape returned focus to its trigger. These are bounded checks, not a full screen-reader or reduced-motion evaluation; including reduced-motion rules in the stylesheet does not establish that evaluation.
What the Checks Actually Showed
The engineering pilot used four PRs and seven pre-labelled requests, with whole PRs separated between development and holdout. These were assistant-created engineering annotations, not independent customer ground truth.
The frozen v8 holdout found the three labelled requests and also emitted one quoted repetition as an extra request. That failure led to a quoted-text selection restriction. The next run is reported as a regression, not a fresh holdout; it still emits an additional agreement/observation as a possible ask. I kept that limitation in the evaluation report.
A later usability failure was in the delivery, not the model: the browser remained open after the local services stopped. The generic error gave no useful recovery path. The interface now distinguishes an offline server from an unavailable model and keeps typed notes in the open tab during reconnection. A real browser check stopped the services, observed the failed save with its draft retained, then reconnected and saved successfully. Expired sessions renew only after a rejected request; no potentially completed write is automatically replayed after a network error. Unsaved notes do not survive closing or reloading the tab.
The first lifecycle fix was incomplete too. Although the Mac jobs had PID 1 as their process parent, macOS still attributed jobs launched from ChatGPT to that app and removed them when it quit. Start ReviewRadar.command now asks the user to launch through Finder/Terminal and restarts only this project's owned jobs instead of reusing those jobs. That may interrupt an in-flight import or analysis, so saved database records and unsaved tab-only notes are explained separately. Launchd restarts crashes only while the jobs remain loaded. Survival after quitting ChatGPT through this new launch path still requires verification; I am not presenting a successful startup as proof. This is a local application, not an always-on hosted service or a login-startup installation.
The recorded checks include backend/adversarial tests, frontend state/workflow tests, type/build checks, an actual GitHub-import-to-inference API run and clean-source installation. The public preview is saved evidence, not a way to disguise unavailable inference. I have not obtained a genuine participant trial or measured a human time-saving percentage, so I make neither claim.
Why Does Open Innovation Matter?
The model is the component that reads the language of the request and considers a later reply. It is central to the feature, rather than an unrelated integration added to a dashboard.
Running open weights locally lets me retain a dated input, inspect the model/prompt/runtime configuration, rerun a case and preserve a failure without paying for another hosted inference call. After installation and import, saved-discussion processing works without internet. Fresh GitHub imports and the initial dependency/model downloads still require a connection. This release supports public PRs, so I am not claiming an unimplemented private-repository privacy feature.
The Gemma artifact and llama.cpp make the core workflow inspectable and replaceable. The repository pins the revisions/checksums used in the demonstration. Local execution still uses memory, electricity and installation time; “no hosted API bill” does not mean free of every cost.
The Human Role
I chose ReviewRadar from the researched Week 3 ideas and asked for careful planning, separate reviews and staged implementation before submission. My contribution history supplied the real discussion examples and the context for the problem. Those are the human inputs I can substantiate.
AI agents assisted research, planning, implementation, testing and this write-up. I am not presenting their work as code I manually typed or an experiment with customers. The app also preserves a human role during use: only the person reading the actual evidence decides what their local review note should mean. A generated “possible response” never closes that decision for them.
Current Limits
The model can miss a request, over-extract agreement or associate a reply poorly. Automated comments remain visible in Sources but are outside the explicitly labelled human-review queue. Large discussions can exceed the bounded context; the app rejects them visibly rather than silently dropping text. Private repositories, background monitoring and code-fix verification are outside this release.
The intended payoff is a calmer way to resume a review session. Whether that saves someone enough total reading and correction effort to become a regular habit is the next genuine-user question, not a result I can manufacture from test counts.
Prize Categories
Overall and Best Use of Gemma. Local Gemma performs the actual request/response interpretation. No additional partner category is claimed for unused or decorative technology.
AI assistance disclosure: AI agents contributed substantially to the code and article. No independent participant trial or human savings claim is asserted.
Top comments (0)