DEV Community: Mohd. Ibrahim Iqbal

Exorcist: a ghost hunter for your package.json

Mohd. Ibrahim Iqbal — Thu, 29 Oct 2026 07:08:46 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Exorcist is a dependency health scanner for package.json — the checks
npm audit doesn't run. Drop in a file (or paste a GitHub repo URL) and it
finds the slow rot every Node project accumulates: deprecated packages,
functional duplicates nobody noticed they installed twice, packages a major
version or more behind, oversized bundles, copyleft licenses hiding in a
permissive project, and dependencies with no publish in two years. It rolls
everything into a single 0–100 health score and tells you what to do about
each finding.

For the theme — Ghost in the Machine — I leaned all the way in: a Victorian
broadside-poster UI, a blood-drip ceiling, flickering candles, a lantern that
follows your cursor, and a results screen presented as a morgue toe-tag.
Findings are "spirits" (Dead, Dormant, Cursed, Ancient, Bloated, Possessed,
and Resurrection for the alternatives it suggests). It's a bit much. That was
the point.

Demo

Live: https://exorcist-hf26-wk4.onrender.com

Click "Try a demo tome" on the landing page to scan a deliberately haunted
package.json — it has lodash+underscore duplicates, deprecated left-pad
and request, and a few other dependency sins, so you can see every check
fire without hunting down a real cursed project first.

No login, no setup, no data leaves your browser — see Privacy below.

Code

ibrahim-iqbal / exorcist-hf26-wk4

Dependency health scanner powered by EmbeddingGemma — Hacktoberfest Week 4

Exorcist

Drop your package.json. See what lurks within.

Live demo · DEV write-up · Design spec

More screenshots

Dark results	Light landing	Light results

Every Node.js project accumulates ghosts: deprecated packages nobody noticed, duplicates doing the same job, bloated bundles dragging down load times, licenses that conflict with yours, and ancient major versions three generations behind. These spirits hide in plain sight inside package.json, haunting your build long after anyone remembers inviting them in.

The invoicing-app fix is npm audit, which covers CVEs but not the slow rot — the functional duplicate you installed because you forgot you already had one, the 200kB library you pulled in for a function that ships with Node, the package whose last commit was in 2022. Exorcist catches those.

Features

Fully local. Your package.json never leaves your machine. The ML model downloads once and runs in the browser tab via WebAssembly. No…

View on GitHub

git clone https://github.com/ibrahim-iqbal/exorcist-hf26-wk4.git
cd exorcist-hf26-wk4
npm install
npm run dev

MIT licensed. Architecture and the full scan pipeline are written up in
docs/DESIGN.md
if you want the "how it actually works" version instead of the pitch.

How I Built It

The stack: React 19, TypeScript, Vite 8, Tailwind v4 for utility spots, and a
hand-built CSS theming layer (custom properties, no CSS-in-JS) for the poster
UI. Framer Motion and plain CSS keyframes handle the atmosphere — drips,
embers, the cursor-following lantern.

The scan pipeline

The scan runs entirely in the browser in seven stages:

Each stage reports progress so the UI can animate the summoning circle in
real time. If any stage fails (model can't load, registry unreachable), the
pipeline degrades gracefully — the checks that needed that data are skipped,
and the rest still run.

The open-source AI piece

EmbeddingGemma 300M
— Google's open-weight embedding model from the Gemma family, running
entirely in-browser via Transformers.js
on ONNX Runtime WebAssembly. No API key, no inference server, no per-request
cost. It does two genuine jobs that keyword matching can't:

Duplicate detection. lodash and underscore share almost no words in their descriptions, but they're functionally the same thing. Exorcist embeds every package's npm description and flags pairs above an 82% cosine-similarity threshold.
Alternative suggestions. When a package is dead or dormant, Exorcist finds the closest healthy package by embedding distance instead of consulting a hardcoded lookup table — if request is deprecated, it can surface axios or node-fetch based on what the package actually does.

If the model can't load — offline, low memory, an older browser without
WebAssembly SIMD — the scan degrades gracefully. Those two checks get skipped
and the other five still run. No crash, no blank screen.

The rest of the pipeline (npm registry lookups, Bundlephobia bundle-size
checks, the scoring model) is plain TypeScript with no AI involved — the
model earns its place for the two checks that genuinely need semantic
understanding, not because "AI" sounded good on a feature list.

Why Does Open Innovation Matter?

Because package.json is basically a map of your stack, your exposure, and
how far behind you are on patches — and I didn't want to ask anyone to upload
that to a server to find out if their dependencies were rotten.

An open-weight model running client-side means:

Privacy by construction, not by policy. There's no backend that could see your file even if I wanted it to. The claim "your data never leaves your browser" is checkable in the network tab, not just written in a privacy policy.
No per-scan cost. A closed embedding API would do the same duplicate detection, but every scan would mean a network call, a cost, and a dependency on that endpoint staying up. EmbeddingGemma is a file, not a service — run it on every project, every day, for free.
Works offline once cached. After the first load, the full scan (minus the npm/Bundlephobia lookups, which are public and anonymous anyway) works without internet.
Inspectable. The 82% similarity threshold, the severity weights, the category caps on the health score — all of it is in the source, and all of it is a number someone can disagree with and change. That's a different relationship to the tool than a black-box API returning a score.

Open-weight models made this flow possible without those tradeoffs. That's
the whole pitch for "open innovation" here: the intelligence lives where the
data already is, instead of the data having to travel to where the
intelligence is.

The Spirit of It

The moment Exorcist stopped feeling like a side project and started feeling
like a real tool was the first time I ran it on one of my own production
package.json files — not the demo, not a test fixture, a project I
actually ship.

It found request. Deprecated since 2020. Still in my dependencies. I knew
request was deprecated — I'd read the notice years ago — but it was still
there, still being installed, still adding weight to every npm install,
because no scan I normally run flags "deprecated but functional." I'd walked
past that ghost every day without seeing it.

Then it found that lodash and underscore were both installed. Different
parts of the codebase pulled them in at different times. They do essentially
the same thing. Nobody noticed because the duplicate isn't visible in a
lockfile diff or a bundle report — you only see it if you compare what the
packages do, not what they're named. That's the check that needs
embeddings, and that's why I built it.

Exorcist is a tool for the kind of technical debt that hides in plain sight:
not security vulnerabilities or breaking changes, but the slow accumulation
of things that stopped being the right choice sometime between when you
installed them and now. The ghosts in your dependency tree aren't dramatic.
They're just quietly making everything a little heavier, a little slower, a
little harder to maintain — and nobody exorcises them because nobody looks.

Now something does.

Prize Categories

Best Use of Gemma — EmbeddingGemma 300M (from the Gemma family) runs entirely in-browser via Transformers.js/ONNX for semantic duplicate detection and alternative package suggestions. No API, no server, no cost.
Best Use of Render — The live demo at exorcist-hf26-wk4.onrender.com is deployed as a Render static site from render.yaml, building from source on every push.

Built for Hacktoberfest 2026, Week 4: Ghost in the Machine.

cubby: I made my wifi password searchable by meaning, not memory

Mohd. Ibrahim Iqbal — Wed, 21 Oct 2026 11:25:00 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

I copy things all day and lose most of them: a wifi password, a docker run line, a flight confirmation, an address. Every notes app says the same thing, organize it first. Give it a title, a tag, a folder. That's the step I always skip.

cubby skips it. You paste something and press enter. Later you type what you remember, in your own words, and it finds the note. No title, no tag, no folder, no account, no server.

That query found "landlord's number: 555-0199, text don't call". The two share no words. An open-weight model, EmbeddingGemma 300M, runs inside the browser tab and ranks your notes by meaning.

On my 20-item test set it found the right note 20 out of 20 times. Plain keyword search found 14 out of 20.

Demo

Live: https://cubby-6mn8.onrender.com (the first load downloads the model, about 300 MB, once)

Everything above is a real capture of the live app with ten sample notes. It also fits a phone screen:

Code

Repo: https://github.com/ibrahim-iqbal/cubby-hf26-wk3

MIT licensed. React 19 + Vite, a static site.

How I Built It

The model measures meaning. It never writes a word.

Last week's HushQuote asked a 270M model to generate text, and most of that write-up is about how it hallucinated. So this time the model only does the one thing small models are reliable at: turning text into an embedding.

Saving never waits for the model. The note is stored first and its vector is filled in behind it. Asking blends two scores, so an exact keyword is never beaten by a weak semantic guess:

The blend is a fixed 0.7 × semantic + 0.3 × lexical.

The test set

20 fixed (note, query) pairs. Each query is ranked against all 20 notes, so a hit means the right one beat 19 others. Every row is in test/queries.md.

Scorer	Right note in top 3
semantic only	20/20
shipped hybrid	20/20
plain keyword	14/20

Twenty is small and I wrote the paraphrases myself, so read this as "works on the case the app exists for", not "solves search". These are the six keyword misses:

query	saved note
refund deadline for the apartment booking	Airbnb Lisbon, free cancellation until Jan 3
sherlock holmes address	123 Baker Street, London NW1 6XE
what flowers should I get for mother	mom's birthday is March 14, she likes tulips
how do I reach the property manager	landlord's number: 555-0199, text don't call
generate a self-signed TLS certificate	openssl req -x509 -newkey rsa:4096 ...
what time is my teeth cleaning	dentist appointment moved to 2:30pm Thursday

What fought back

300 MB on first load. A service worker caches the weights, so later visits are instant and work offline. The first visit shows a live log of each shard instead of a fake progress bar.
256 dimensions, not 768. I keep the first 256 of EmbeddingGemma's 768 and renormalize (Matryoshka truncation, which the model is trained for). Vectors are a third the size and recall on my set didn't change. The model also wants task prefixes, so a query gets task: search result | query: and a saved note gets title: none | text:.
Word matching was too strict. The first version needed a whole word, so "doc" found nothing until I'd typed "docker". It now scores exact, prefix and substring matches per token.
If the model fails to load, cubby falls back to keyword search and says so in the footer.

Checking the privacy claim yourself

"Nothing uploaded" is easy to claim, so I measured it. On the live build I loaded the page and let the model finish, then started logging network requests, saved ten notes, ran three searches and switched through all ten theme and mode combinations.

requests after load: 0

Two things to know. The first visit downloads the model from huggingface.co. And on later visits a small generation_config.json request to the same host can still show up, which lets Hugging Face see your IP and browser like any web request. To repeat the test, open DevTools, go to Network, clear the log after load, then use the app. I didn't test the export button.

Why Does Open Innovation Matter?

The model is a file, not a service. No API key, no per-call bill, nobody who can change the pricing. A hosted embedding API would mean sending every note you save to someone's server, which is the thing I wanted to avoid.
You can check the privacy claim. Inference happens in your tab, so you can verify it in DevTools instead of taking my word.
I could test what was inside. The truncation and the task prefixes are documented behaviour of the open model, and I checked both against my own test set.
It works offline. The shell and the weights are cached, so it keeps working without signal.

What it saves you

Saving costs one paste and one keypress.
Finding costs one sentence. On my set, keyword search sent me hunting for 6 of 20 notes; EmbeddingGemma sent me hunting for none.
Once warm, one run on the live site showed results about 170 ms after I entered a query. That's one measurement, not a benchmark, and it will grow with a bigger collection.

I haven't measured hours saved, so I'm not claiming any.

What's still missing

Text only: no images, no OCR.
No sync between devices. JSON export and import is the only way to move data.
Hybrid ranking narrows the cases where the two scores disagree but doesn't remove them.
Share-to-cubby on Android is implemented through the PWA share target, but I haven't tested it on a real phone, so I'm not showing a screenshot of it. Safari on iPhone has weak support, so paste manually there.

Prize Categories

Best Use of Gemma. EmbeddingGemma 300M is the whole retrieval engine. Every ranked result exists because that model embedded the note on-device. It never generates text.
Best Use of Render. A static site with no backend, deployed from the repo's render.yaml blueprint and redeployed on every push.

Try it

Live: https://cubby-6mn8.onrender.com
Repo: https://github.com/ibrahim-iqbal/cubby-hf26-wk3
Five themes in light and dark, each checked for WCAG AA contrast with test/contrast.mjs:

HushQuote: quotes that stay yours

Mohd. Ibrahim Iqbal — Wed, 14 Oct 2026 09:49:44 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 2 - Side Hustle

What I Built: HushQuote. Speak a job description, get an itemized, editable quote - then a PDF. A small open-weight model (Gemma 3 270M) runs entirely inside the browser tab, on WebGPU when it's there and WASM when it isn't. No account, no server, no install. The client's name and the day rate never leave the device they were typed on.

Try your own phrasing, not just the demo's. If a line shows up that you never said, that's a known model quirk documented below, not a broken app - tap the × to drop it; totals recompute instantly either way.

The problem

Every tradesperson I know who works for themselves does the same thing after a job: sits in the van, opens a notes app or a half-remembered Excel template, and tries to turn "forty square meters, two days, plus materials" into something a client will actually pay against. Then they either forget a line, round a number wrong, or just don't send the quote for three days because writing it feels like a second job.

The invoicing SaaS market solved this with a $15/month subscription and an account you have to make, for software that's worse at the one job that actually matters: turning what you just said out loud into a document. That's the gap HushQuote is built for - it's cheap enough to be a real side-hustle tool, not a line item.

What I built

The whole app is one living document, not a wizard:

The Margin - a rail on the side holding your raw words in monospace, dictation-tape style.
The Sheet - an always-visible, real quote document. Line items typeset directly onto it as the model reads your words.
The Command Bar - mic or textarea, one submit button, nothing else.

Say or type the job. The model reads it into structured line items - description, quantity, unit, rate - and they land on the sheet looking exactly like what you'd hand a client, except every model-sourced line is visually provisional: a dashed border and an "Estimated. Yours to set." label, until you tap to confirm it. Math is never done by the model; totals are always computed in plain JavaScript from whatever's actually on the sheet.

A Dashboard sits in front of the Sheet once you have more than one quote going: every saved quote in one list, with stat cards for quote count, total quoted value, and how many lines across all your drafts are still sitting on a model's estimate instead of your own number.

How I built it

Stack, at a glance:

Runtime: React 19 + Vite, deployed as a static site on Render - no backend, no database, nothing running server-side at all
Model: Gemma 3 270M-instruct (Q8_0 GGUF), via wllama (llama.cpp compiled to WebAssembly/WebGPU), downloaded once into the browser tab
Validation: zod schemas (src/lib/schema.js) checking every model response before it reaches the sheet
Storage: localStorage only - quotes, business profile, and rate library never leave the device
PDF export: the browser's native print dialog, no added dependency

The model only extracts. The app decides what's true.

That's the one sentence that governs every design choice here. A 270-million-parameter model is small enough to ship as a file instead of a service, but it is also small enough to be wrong in specific, repeatable ways - so nothing it says is trusted until code checks it.

Concretely:

Structured output, not a hopeful prompt. wllama's createChatCompletion supports OAI-compatible response_format: {type:'json_schema'} natively - the model is sampling against a grammar that only lets valid tokens through, not just being asked nicely for JSON.
Everything still gets zod-validated. A grammar guarantees the braces close; it says nothing about whether the content inside them is right. Every response goes through a real schema check before it touches the sheet.
One repair generation, then honest surrender. If the first response fails validation, the model gets one more try with the exact error attached. If that fails too, the app does not guess - it drops back to manual mode and the user types the line themselves. A bad extraction costs a few seconds, never a wrong number going out silently.
The model never sees or touches the totals. Subtotal, tax, and total are pure functions over whatever line items are actually on the sheet (src/lib/totals.js) - they recompute instantly on every edit, independent of what the model ever said.

What I got wrong, and how I know

I ran all 20 of my own test transcripts (test/transcripts.md) through the real pipeline rather than trusting the two I'd eyeballed early on, and the results were worse, and more specific, than I expected.

#	Job	What happened
1, 3	Bathroom tiling (clean / with correction)	Correct
6, 16	Garden cleanup / fence staining with a price correction	Mostly correct - 16 even picked up the corrected rate, not the original
2, 7, 13	Logo package / tap repair / photography	Real job fragmented into 2-3 duplicate lines, flat fees landed in the wrong field
4, 8, 10, 11, 12, 18, 19	Fence, deck rebuild, painting, electrical, Chen deck, gutter cleaning, drywall	Right-ish first item, plus a fabricated "Callout" line that doesn't exist anywhere in the transcript
5, 17	Lawn+hedges / dog walking	Right item count, duplicated 2-5x, wrong units
9, 14	Blog posts / callout+valve	Model ignored the real transcript and echoed an unrelated internal example almost word for word
20	"Just an inspection, no numbers"	Model invented a fully priced fake quote for a job that explicitly had no numbers in it

That "Callout" line showing up in 10 of 18 fresh runs turned out to be my own few-shot example leaking into unrelated outputs - not a rate-library bug, confirmed by clearing the rate library mid-test and watching it persist. Transcript 20 is the one that actually matters: a model inventing prices for a job the user described as having none is exactly the failure "the LLM extracts, the app calculates" exists to make survivable, but a quote that reaches the pending-chip UI with a confidently wrong number on it is still a UX cost, even if it's a recoverable one.

I tried the obvious fix - dropping the few-shot example entirely and relying on the JSON schema alone. It killed both of the worst cases, but introduced a new one (the model wrote the literal string "${1}" as a description on every line). Not a clean win either way, so I shipped the known, documented behavior instead of an unproven swap days before the deadline. Full writeup, including a confirmed-separate truncation bug and its fix, is in docs/RISKS.md.

Update, after publishing: shipped the narrower fix instead. src/lib/filterHallucinations.js drops a model-output line when its description is a bare "callout" and the transcript never said any form of that word - the single leak that hit 10 of the 18 transcripts above. It's deliberately narrow: "Labor" leaks the same way sometimes, but "Labor" is correct far more often than it's a leak (transcript 1's "two days labor" needs that line to survive), so the same bare-word check there would trade a rare false positive for a common false negative. It does not touch the other two failure rows (9/14's verbatim echo, 20's fully invented quote) - those need the model to recognize it has no grounding at all, which a regex over one field can't do.

Here's the safety net those two unfixed rows still rely on, in case you hit either one: tap the × on a wrong line, the total recomputes immediately.

Why open innovation matters here

The model is a file the app ships, not a service you rent. No API key, no per-request bill, no vendor who can change pricing under you. The entire cost of running this for a thousand quotes is the same as running it for one.
Client names and day rates never leave the device. A plumber's client list is exactly the kind of data a side-hustle tool shouldn't be phoning home with, and "trust us" isn't verifiable the way "look, no network tab activity" is.
It works with no signal. A job site with no wifi and bad cell coverage is a normal Tuesday for a tradesperson. Closed APIs don't work there. This does.
Running it myself, honestly, instead of hiding the rough edges, is also the open-source story: the 20-transcript table above exists because I could actually inspect why the model did what it did, and the fixes I made (schema validation, the repair step, the token-budget bump, and now the Callout filter) are fixes to my own code, not a support ticket to a vendor.

How this is different from the other Side Hustle freelance tools

A few other Week 2 submissions land in the same space - invoice and receipt sorters for freelancers. The closest ones (InvoicePilot AI, VaultLedger AI, FreelanceAI) are all built the same way under the hood: Ollama or a Python backend the user has to install and run alongside the app. That's "local" in the sense that your data doesn't leave your machine, but it's not "no install" - you're still standing up a server process first.

The one submission actually in the same product category - turning a messy brief into a priced estimate, not sorting receipts - is ScopeCraft, a genuinely good build around Qwen3-0.6B. Even it runs a small Node HTTP server locally to serve inference. HushQuote has no server step at all, local or otherwise.

HushQuote has no backend at all, not even a local one. It's a static site. The model downloads into the browser tab itself and runs there via WebAssembly/WebGPU. Close the tab, and there's nothing left running on your machine to manage. That's a stronger version of the same privacy pitch, and it's the actual reason this is a PWA instead of a desktop app.

Prize Categories

Best Use of Gemma - Gemma 3 270M-instruct is the only model HushQuote ships, and it's the entire extraction pipeline: every line item on the sheet exists because this model read the transcript, not a cloud call standing in for it.
Best Use of Render - the live deploy (hushquote.onrender.com) is a Render static site, auto-deploying on every push to main with no build server of my own to maintain.

What's next

The deterministic regex co-extraction pass flagged in docs/RISKS.md as the next real lever on the two still-unfixed failure rows (verbatim echo, invented-quote), if there's time.
Finding an actual tradesperson to hand this to and reporting back what they asked for next - the challenge's bonus round, not done yet at time of writing.

Try it

Live: https://hushquote.onrender.com
Code: https://github.com/ibrahim-iqbal/hushquote
Full build log / decisions / bugs found: docs/PLAN.md and docs/RISKS.md in the repo - the honest version of this post, day by day.

Touch Grass: voice dares that get you off the screen, running on-device with Gemma 3 270M

Mohd. Ibrahim Iqbal — Sat, 10 Oct 2026 18:20:41 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Touch Grass — say how much time and energy you've got, and it gives you one short, concrete dare to go do outside. Finish it, snap a photo as proof, and it counts toward a daily streak. No feed, no infinite scroll, no "just one more dare" loop — one dare, go outside, come back later.

It's a PWA: install it, and after the first load it keeps working with no signal, because the shell and the model are both cached by a service worker.

Who it's for: anyone who opens their phone meaning to do one quick thing and surfaces 40 minutes later having done none of them. Tell it you've got 10 minutes and low energy, it won't give you a half-marathon.

Demo

🔗 Live: https://touch-grass-bkii.onrender.com
💻 Code: https://github.com/ibrahim-iqbal/touch-grass

The whole app is a little outdoor world you stand in. The painted pixel-art scene fills the screen, your character stands in the grass, and the controls sit at the edges like a game HUD — nothing floats in a box over the middle.

Flip the theme and the same world re-lights from a cozy night to a warm daytime — the backdrop art crossfades, the moon slides out and the sun comes up.

Tap the mic, say your time and energy, and a dare slides up from the bottom in a dialogue ribbon — tagged with roughly how long it takes and how much it'll cost you — with a "prove it outside" button that opens the camera.

ibrahim-iqbal / touch-grass

voice dares that get you outside — local gemma, zero backend

touch grass

voice dares that get you outside. say how much time and energy you have it gives you a short outdoor dare, you snap a photo as proof when you're done.

built for the hacktoberfest open-source ai challenge, week 1: "touch grass."

why open

dare generation runs on-device with gemma 3 270m via transformers.js, not a hosted api
works after the first load even with no signal — service worker caches the page and the model
nothing you say or type leaves your browser; your hugging face token and elevenlabs key (both optional) are stored locally and used directly from your device
swap the model, edit dares.json, or rip out the generation step entirely — it's all plain js

running it

just a static site, no build step.

python3 -m http.server 8000

open localhost:8000. voice input needs chrome or edge (web speech api support is patchy elsewhere)…

View on GitHub

Voice input needs Chrome or Edge (Web Speech API support is patchy elsewhere). Camera proof needs HTTPS or localhost — both are satisfied on the live link.

How I Built It

Plain HTML/CSS/JS, no framework, no build step, no backend. A few deliberate choices:

Default mode needs zero setup. Say your time/energy/place, it matches you against a small curated dare bank (dares.json) and speaks the result with the browser's own speechSynthesis. This always works, offline, with nothing to configure.
Optional smart layer: Gemma 3 270M via transformers.js. Paste a Hugging Face token into settings and dare generation switches to the model, running entirely in your browser via WASM — not a hosted API call. Nothing about your request ever leaves your device.
Optional voice layer: ElevenLabs, same pattern — your key, used directly from your browser, swappable back to the built-in voice at any time.
The UI is a game HUD, not a form. The painted pixel-art world fills the screen and your character stands in it; the level, stats and controls pin to the corners like an RTS, and each dare appears in a slide-up dialogue ribbon like an RPG. The backdrop art is day/night and crossfades when you toggle the theme, with a sliding sun/moon, drifting clouds and foliage that fills in as your streak grows.
A service worker caches the app shell so the whole thing — including the model, once downloaded — works with no connection after the first load. That's the actual point of the "touch grass" theme: the app should survive exactly the situation where you're outside with no signal, which is where it's most useful.
Cross-origin isolation (COOP/COEP) configured on the Render deploy so the WASM runtime gets the full, fast execution path rather than a degraded fallback.
Camera proof uses getUserMedia + canvas, with a defensive timeout — confirmed by hand that getUserMedia can hang indefinitely on a device with no camera rather than reject, which otherwise traps the UI with no way out.
Deployed on Render as a static site, auto-deploying from main on every push.

Why Does Open Innovation Matter?

Two reasons this specific shape only works because the model is open-weight:

It can genuinely run with nothing hosted by me. There's no backend, no API key of mine in the loop, no bill that scales with usage. A user who wants the smarter dare generation brings their own free Hugging Face token and the model downloads and runs on their device. I can't see their request, because it never reaches a server I control. A closed API would force a hosted proxy — which means a cost center, a privacy boundary I'd be asking users to trust, and a single point of failure the moment I stop paying the bill.

It made "fully optional" actually honest. Because Gemma 3 270M is small enough to run client-side, the "smart" mode isn't a crippled free tier nudging you toward a paywall — it's a real optional upgrade with a real reliability floor underneath it (the curated dare bank) that works identically whether or not you ever touch the settings gear. That's a hard thing to build honestly on top of a closed, metered API; it's the default shape of an open-weight one.

Prize Categories

Best Use of Render — static site, deployed and auto-deploying from this repo, with COOP/COEP headers configured for the WASM runtime
Best Use of Gemma — Gemma 3 270M running fully client-side via transformers.js for live dare generation
Best Use of ElevenLabs — optional nicer voice output for the spoken dare, key used directly from the browser

OSS Buddy: a local Gemma that picks weekend-sized issues so my cousin can finally land his first PR

Mohd. Ibrahim Iqbal — Fri, 02 Oct 2026 17:52:59 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I have a cousin. He has been telling me he wants to contribute to open source for about a year. Every month or two he sends me a screenshot of a repo and asks "is this a good one to start with?" I say yes. He opens it, scrolls for twenty minutes, closes the tab. The screenshot never turns into a PR.

I used to tell him "just pick a good first issue." That advice is useless. Good first issues live in repos with four hundred files and eighty open issues each. You still have to pick. He had already been doing that for a year.

So I built OSS Buddy. You point it at any GitHub repo and a local Gemma 3 model tells you three things in about twenty-three seconds:

What the project actually does, in two plain sentences
Up to three good first issue tickets ranked easiest to hardest, with time estimates
Which specific directory to start reading

Nothing leaves his laptop. No account, no API key, no credit card. He downloads Gemma once, forgets about it, the tool works forever.

Demo

One command, no cloud calls. Terminal recording against kiwix/kiwix-android.

Benchmarks on five real repos

Measured end-to-end on an M-series Mac with Gemma 3 4B via Ollama. Each run is one command, no warmup, no cache.

Repo	Stack	Runtime	Good-first-issues found
kiwix/kiwix-android	Kotlin	27.9s	6
simonoppowa/OpenNutriTracker	Flutter	23.5s	3
RetroMusicPlayer/RetroMusicPlayer	Kotlin	22.1s	6
neovim/neovim	C	22.0s	0 (no `good first issue` label)
fastapi/fastapi	Python	22.0s	0 (none open at test time)

Average: ~23 seconds, zero cloud bytes. The two zeros are honest limits — neovim doesn't use the good first issue label at all, and fastapi had none open when I ran it. OSS Buddy says so plainly rather than hallucinating issues.

Code

ibrahim-iqbal / oss-buddy

A local Gemma 3 reads any GitHub repo and picks weekend-sized good-first-issues for your friend. Nothing leaves your machine.

OSS Buddy

Point it at a GitHub repo. A local Gemma 3 model reads the README, the top-level file tree, and the open good first issue tickets, then tells you:

What the project does, in plain words
Up to three issues that look weekend-sized, ranked easiest to hardest
Where in the repo to start reading

Nothing leaves your machine. Your GitHub token stays local. The model runs on your laptop via Ollama.

Why

A friend of mine kept opening huge OSS repos, scrolling for twenty minutes, closing the tab. He wanted to contribute. He did not know where to start. Every guide said "pick a good first issue" and every repo had dozens.

This reads the repo for him and says "here, pick one of these three start reading here."

Install

Needs Python 3.9+, the GitHub CLI, and Ollama.

# ollama (macOS)
brew install ollama
brew services start ollama

…

View on GitHub

~150 lines of stdlib Python. No pip install. MIT.

How I Built It

Open-source AI used:

Gemma 3 (4B) — Google's open-weight model, running on my laptop
Ollama — open-source runtime for the model
GitHub CLI (gh) for repo data

Pipeline (lazy on purpose):

    gh api  (readme + top-level tree + good-first-issues)
                        │
                        ▼
                 one tuned prompt
                        │
                        ▼
         POST localhost:11434 (ollama)
                        │
                        ▼
                   gemma 3 4b
                        │
                        ▼
         stream the answer to the terminal

Three HTTP calls to GitHub, one HTTP call to a server running on my own laptop. That is the whole pipeline. The Python file is small enough to read in one sitting.

The prompt went through three real iterations in the git history. The first version produced great summaries but ended every answer with "Would you like me to delve deeper?" — chatty, off-brand. The second version started paraphrasing issue titles instead of quoting them, which was worse than useless because then you couldn't grep for the issue on GitHub. The third version pins Gemma: "Quote the issue number and the EXACT title from the data below. Do not paraphrase or invent." That one shipped.

Labels aren't consistent across repos

Early version only looked for the literal good first issue label. Lost half the repos. The fix was a cheap one — try the three common spellings in order:

for label in ("good first issue", "good-first-issue", "beginner"):
    ...

Simple, but it is the difference between the tool working on one repo in two and almost all of them.

Why Does Open Innovation Matter?

He does not need to sign up for anything before he can start contributing to open source. He already has GitHub, git, and a dozen tabs open. A new contributor does not need another sign-up flow before the one he actually came for. Open-source AI removes that friction entirely — he downloads the model once, forgets about it, and the tool just works.

The second thing matters more. His GitHub token and the repos he explores never leave his laptop. Some of those repos are private — half-built side projects, work stuff. A closed API would have meant sending every README and every issue title to a third party's servers. With Gemma running locally that whole class of problem does not exist.

The third thing is practical. It runs on a plane. It runs in a cafe with slow wifi. It runs inside offices that block third-party API calls. It costs zero rupees forever. For someone taking their first step into open source every friction point is a chance to quit — the open stack removes a few of them.

And the whole chain is readable. 150 lines of Python. An open-weight model with public weights. A runtime with public source. If my cousin wants to see what the LLM did with his repo, he can trace it from his terminal all the way down to the weights. That is the open-source story — not just the model, the whole stack.

The hand-over

I sent him the install snippet on WhatsApp — three commands, no sign-up, no API key.

He hasn't run it yet as of this edit. I'd rather say that plainly than leave a placeholder sitting in a published post. The honest version of "built for a friend" includes the part where the friend hasn't gotten to it yet — that's a real, common outcome of building something for someone else's spare time, not a reason to dress it up. I'll update this section the moment he does, with whatever he actually says, not a tidied-up version of it.

My Agent Session

Skipping DevRelay sessions on this one. The story is in the git log instead:

31b5e08 initial scaffold: fetch readme + good-first-issues via gh
4a8dbb5 wire up ollama + first prompt that asks for 3 ranked issues
ede3d7f tighten prompt (no outro, quote exact issue titles)
b430d72 add demo gif + vhs tape
bf1babc readme: link to the dev.to writeup
0d26567 readme: proper case + benchmarks table + cover image

Six commits, a few hours of work spread across one evening and the next morning.

What's next

Short list, in the order I'd attack them:

Deeper issue analysis. Right now it reads the issue title and body. Next step: fetch linked files and the diff of the last PR to touch them, so "where to start" becomes line-level, not directory-level.
Remember what my cousin has already tried. A tiny local SQLite log of attempted issues so OSS Buddy stops suggesting the same ones.
A thin web wrapper for people without Ollama. Deployed somewhere small (likely a free Render tier) that calls a hosted Gemma via Groq. The CLI stays local-first; the web version is a convenience.
A --contributing flag that reads the project's CONTRIBUTING.md and tells you what tests to run and how to open a PR, so the suggestion ends with "and here is exactly how this project wants it submitted."

None of it changes the shape of the tool. It's all deeper reading of the same three sources.

Prize Categories

Best Use of Gemma — Gemma 3 (4B) via Ollama is the only model used. The entire pipeline depends on it. No fallback, no closed-model path, no "bring your own API key." Just Gemma, local, free.