SlothContributor: a local agent that does my issue hunting
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:
!kestra-io/kestra run on area/backend label
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
{% youtube RI2ETJanHFI %}
Code
{% github flash-source/sloth-contributor %}
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:
1. Suggest: Gemma reads the issue and proposes likely file paths.
2. Verify: the Python backend fetches those files from the GitHub API.
3. 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.
1. 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.
2. 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.
3. 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!
1 reaction
Mentions
My First Steps into Open Source with Kestra Really enjoyed participating in Hacktoberfest and contributing to Kestra! 🎉 As someone getting started with open source, I found the experience really rewarding. The good first issues made it easy to get started, understand the codebase, and make meaningful contributions. Here's my contribution: kestra#20437 Looking forward to contributing more! 🚀 #Hacktoberfest #KestraHacktober #Kestra
My first open-source contribution to Kestra has been merged! I’m happy to share that my first PR to Kestra has been merged as part of #KestraHacktober! 🔗 PR: kestra#20872 The contribution involved refactoring the TaskArray.vue component's styling, removing Bootstrap utility classes and replacing them with custom CSS while aligning the component with Kestra's design system. It was a great learning experience working with an established open-source codebase, understanding its existing conventions, addressing review feedback, and getting the changes merged. Thanks to the Kestra maintainers for reviewing the contribution and helping me learn along the way! Looking forward to contributing more to open source. #KestraHacktober #OpenSource #Kestra
Contributing to @kestra_io for #KestraHacktober 🎉 My merged PRs improve default-filter test coverage and the context documentation menu. Learning a lot through fixes, tests, and maintainer feedback! 🔗 kestra#20874 🔗 kestra#21133 t.co
SlothContributor: a local agent that does my issue hunting 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: !kestra-io/kestra run on area/backend label 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 {% youtube RI2ETJanHFI %} Code {% github flash-source/sloth-contributor %} 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: 1. Suggest: Gemma reads the issue and proposes likely file paths. 2. Verify: the Python backend fetches those files from the GitHub API. 3. 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. 1. 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. 2. 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. 3. 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!
We're only 48 stars away from 30k! If you haven't starred Kestra yet and want to sponsor us, star us! kestra-io/kestra
My @kestra_io PR #21339 is merged! 🎉 Updated core examples: Log for messages, OutputValues for downstream data and Return for debugging non-sensitive values. Clearer examples, no runtime changes. @arsh_goyal #KestraHacktober kestra#21339
1/3 My 5th PR across @kestra_io repos is merged! 🎉 Seven execution/concurrency tests were doing extra input, logging or sleep work unrelated to their assertions. This PR gives them smaller test flows. @arsh_goyal #Hacktoberfest kestra#20924
Title: My contribution to Kestra was completed and the issue is closed! 🎉 Hey everyone! 👋 I'm excited to share a milestone in my open-source journey. I contributed to Kestra, an open-source orchestration platform, by working on issue #18143, related to the Flow Editor's split horizontal and split vertical functionality. The issue is now closed, and QA has been completed! ✅ This experience helped me learn more about contributing to a real-world codebase, working with maintainers, and improving my open-source development skills. Thanks to the Kestra team for reviewing and testing the fix! 🔗 Issue: kestra#18143 I'm looking forward to contributing more to open source. 🚀 #OpenSource #Kestra #KestraHacktober #Hacktoberfest
My @kestra_io Hacktober contribution: one Bootstrap class walked into a Vue component, and a scoped CSS rule with --ks-spacing tokens walked out. PR here → kestra#20648
My first PR to @kestra_io got merged! 🎉 Grateful to the team, especially @CharmingData, for the review and merge. Thanks @arsh_goyal for the opportunity! PR: kestra#20420 #KestraHacktober #OpenSource t.co