This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
Confession
I want to contribute to open source, but I hate the hustle. I used to spend 30 minutes refreshing GitHub, filtering labels, reading long issue threads and guessing which files caused a bug. By the time I understood the codebase, I was too tired to write the fix or the issue was already solved.
I wanted to stop searching manually. That became SlothContributor, a local CLI agent that watches my favorite repositories. When a new issue drops, a notification pops up, and the agent has already read the issue, fetched the likely source files and written a structured "Contributor's Hunch" on where to look.
What I Built
SlothContributor is a local-first, AI-powered CLI agent that watches your favorite open-source repositories for new issues.
Instead of manually refreshing GitHub, reading massive issue threads, and trying to understand unfamiliar codebases, SlothContributor automates the entire research phase. The second a new issue drops, it doesn't just notify you. It reads the issue, fetches the relevant source code from the repository, and hands you a structured "Contributor's Hunch" on exactly where to look and how to fix it.
- What effort does it save? It eliminates the 30–45 minutes of tedious context-switching, tag-filtering, and codebase archaeology usually required just to start a Pull Request.
- Who gets to be a little lazier? Open-source contributors and developers who want to focus purely on the creative part (writing the code) while letting a local AI agent do the heavy lifting of finding, filtering, and analyzing the work.
Here is a real run on kestra-io/kestra:
Issues it has already analyzed are skipped, so I only see new ones. I open my terminal, let the agent do the hunting, and spend my time writing the fix.
Demo
Code
🦥 SlothContributor: Local AI OSS Issue Sniper
Slow and Steady wins the race. SlothContributor is a local-first CLI agent that watches your favorite open-source repositories. When a new issue drops, it reads the issue, fetches the likely source files and hands you a "Contributor's Hunch" on where to look and how to fix it.
🌟 Why this exists
Contributing to open source is rewarding, but finding a good issue, reading a long thread and working out which files matter takes a lot of time before you write any code. SlothContributor automates that research so you can spend your time on the fix.
It also helps you decide whether an issue is for you. The hunch gives you the core problem, where to look and a suggested fix, so you can tell if you understand it and can solve it before you ask to be assigned.
🏆 Why open models matter
…How I Built It
The core is a Python CLI that talks to Ollama, running Google's open-weight Gemma 2 (2B) locally. I chose it because it's fast and runs on my laptop.
My first version just asked Gemma to read the issue and suggest a fix. On unfamiliar repos the small model was a confident guesser, and it would invent generic paths like src/App.js or config.json in a Java backend.
So I took the guessing away from the model and wrapped it in a suggest, verify, analyze loop:
- Suggest: Gemma reads the issue and proposes likely file paths.
- Verify: the Python backend fetches those files from the GitHub API.
- Analyze: if a file exists, Gemma analyzes the real code alongside the issue. If it returns a 404 because the model made the path up, the agent falls back to the issue text alone and gives a shallower hunch.
Gemma is no smarter this way, but a wrong guess now costs a 404 in the log instead of a bad answer.
I added MongoDB Atlas for persistent memory (no duplicate analysis, resumable sessions), Plyer for desktop notifications and Rich for the terminal UI.
Watch mode
python main.py --watch starts the watcher. It checks the repos in my session every 15 minutes and sends a desktop notification when a new issue drops, even if the terminal is minimized. That way I see an issue while it's still fresh instead of stumbling on it days later.
Two defaults live in config.yaml:
poll_interval_minutes: 15 # how often the watcher checks each repo
max_issues_per_scan: 3 # max issues analyzed in one run
The cap keeps a scan from looping forever and keeps me inside GitHub's API rate limits. Both values can be changed in config.yaml if you want a faster or wider sweep.
Why Does Open Innovation Matter?
For this tool, local inference is a requirement.
- Privacy. The LLM step runs on my machine, so no third-party model provider sees which repos I watch, which issues I pick or what fixes I draft. The tool still calls the GitHub API and stores history in my own Atlas cluster.
- Cost. An agent that polls continuously and puts full file contents in its prompts would get expensive on a paid API. Running Gemma locally costs nothing per scan.
- Control. The loop passes intermediate data between steps, and a local model lets me control prompts and output formats without LLM API rate limits or content filters getting in the way.
My Agent Session
Reasoning runs locally through Ollama. File fetching goes through the GitHub API, and issue history and sessions are stored in my own MongoDB Atlas cluster. I didn't use any hosted agent-tracing tools, so there is no cloud session trace. The logs and hunch history live in MongoDB.
The Lazy Payoff
I've been contributing to Kestra, and the slow part was never the code. It was getting the context of an issue, finding the exact file involved and working out an approach. That could eat a big chunk of time before I'd written anything, and sometimes I'd comment to get assigned without really knowing if I could solve it.
Now the hunch gives me a summary of the issue, where to look and a suggested fix up front. I can tell quickly whether an issue is one I understand and can actually solve, and only then ask to be assigned, instead of leaving a vague comment and figuring it out afterwards. It's a 2B model, so I still read the issue myself, but I start from a direction instead of from zero.
This month I've had three PRs merged in kestra-io/kestra (#20389, #20479, #21076).
Building SlothContributor made me realize that understanding a problem deeply matters just as much as the time and effort you invest in solving it. The tool doesn't just find issues faster, it forces me to think about what makes an issue actually solvable before I even start coding.
For example, when it found the UploadFiles trailing slash bug, the hunch immediately identified the exact YAML properties (filesMap and destination) that needed fixing and even showed me the corrected code structure, saving me from hunting through multiple plugin files.
Prize Categories
- Best Use of Gemma: used Google's open-weight Gemma 2 (via Ollama) as the core reasoning engine of the suggest, verify, analyze agent, running inference 100% locally.
- Best Use of MongoDB Atlas: used Atlas as the persistent memory layer to store analyzed issues, manage interactive sessions and prevent duplicate processing across restarts.
Built with 💖 for the Hacktoberfest 2026 Open-Source AI Challenge. Stay lazy, contribute smartly!
Top comments (1)
Wrapping Gemma 2 in a GitHub API validation step is a clean way to handle hallucinations on unfamiliar codebases. A 404 in the log is much cheaper than letting a small model spin on imaginary paths.
One edge case I ran into with similar watcher agents is repo structure drift across branches. If a contributor works against an older release branch or an active PR renames directories, verifying strictly against the default branch HEAD occasionally discards a valid hunch. Passing the target branch context or falling back to a quick git tree lookup before marking it a missing file helped keep the hit rate up on multi-branch repos.