DEV Community: Aarya Shirsath

sloth-standup: a standup writer that reads my git log so I don't have to

Aarya Shirsath — Thu, 22 Oct 2026 13:45:21 +0000

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

What I Built

sloth-standup reads the git history of my active repos and writes my standup for me: what I did yesterday, and what I'm continuing today. One command, under 30 seconds, and the result is saved as a markdown file.

I contribute to several open-source repos at once, and every morning I'd stare at git log trying to remember what I'd actually done. Now I don't have to. It's for anyone who juggles multiple projects or has to post a daily update and would rather not write it.

Demo

Real output from my own repos, generated by a 3B model running on my laptop CPU:

PS> python -m sloth_standup --since "30 days ago"
Yesterday:
- SecureFlow: Fixed insufficient VRAM handling; Added LLM explanation caching
- iloveAgents: Updated agent categories; Added documentation
- hiero-bot-py: Fixed DCO logic sharing; Added empty-check label verification; Updated test-file regex anchoring

Today:
- SecureFlow: continue fix/local-model-graceful-degradation
- iloveAgents: continue docs/update-category-list
- hiero-bot-py: continue fix/pr-quality-gates

(saved to standups\2026-10-22.md)

Code

Aarya0706 / sloth-standup

Writes your daily standup from your git commits. Runs on a local open-weight model (Qwen2.5), no API key, nothing leaves your machine.

sloth-standup

A lazy, fully local git standup bot. It reads your commits, uncommitted work and open PRs, then an open-weight model running inside Python writes a two-line standup. No Ollama, no server, no API key, no data leaving your laptop.

Setup

pip install -r requirements.txt
copy config.example.json config.json      # then edit your repo paths
python -m sloth_standup --dry-run         # check what the model will see
python -m sloth_standup                   # first run downloads ~1 GB, once

If pip install llama-cpp-python tries to compile and fails on Windows, use the prebuilt CPU wheels:

pip install llama-cpp-python --extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cpu

Already have a GGUF file? Set "model_path": "C:/models/your-model.gguf" in config.json instead of model_repo/model_file.

Make it lazy (Windows)

schtasks /Create /SC DAILY /TN "SlothStandup" /TR "\"%cd%\run_standup.bat\"" /ST 08:30

Your standup lands in standups/YYYY-MM-DD.md every morning.

Options

python -m sloth_standup --since "2 days ago" --repo

…

View on GitHub

How I Built It

Model: Qwen2.5-Instruct in GGUF (q4_k_m), run locally on CPU. I tested the 1.5B and 3B versions.
Git layer: gitdata.py pulls commits and diff stats from each repo listed in config.json, filtered to my author name and capped at 2,500 characters per repo so the prompt stays small.
LLM layer: llm.py summarizes each repo's work at temperature 0.2 with a tight token limit, in a fixed "short items separated by semicolons" format.
CLI: cli.py assembles the Yesterday/Today output and saves it to standups/. The "Today" section comes from each repo's current branch name, so it costs zero tokens.
Config: one JSON file holds the repos, the author, and the model. Swapping models is a two-line edit. A run_standup.bat lets me double-click it each morning.

1.5B vs 3B, on my real repos

	Qwen2.5-1.5B	Qwen2.5-3B
Download	~1 GB	~2.1 GB
Run time (3 repos, CPU)	18.6 s	28.1 s
SecureFlow	Fixed VRAM issue; Added Redis cache for LLM explanations	Fixed insufficient VRAM handling; Added LLM explanation caching
iloveAgents	Updated agent category list; Fixed typo in documentation; Added new feature for user authentication	Updated agent categories; Added documentation
hiero-bot-py	Fixed PR health and quality gates; Improved DCO logic and cache commits; Fixed empty-check label audit, verified DCO trailers, anchored the (cut off)	Fixed DCO logic sharing; Added empty-check label verification; Updated test-file regex anchoring

The 1.5B is about 10 seconds faster, but it invented two items for iloveAgents ("fixed a typo", "added user authentication") when my only commit there was a docs update to the category list. One of its hiero-bot-py items also ran out of tokens mid-sentence. The 3B was vaguer in places ("Added documentation") but didn't make anything up and stayed in the format. For something I'd paste into a standup without rereading closely, the 3B is the one I keep.

Things I learned

Filter by author. My first version summarized everyone's commits in the repo, so my standup claimed other contributors' work as mine. My identity was also split across two emails (one a GitHub noreply address), so matching on my name worked where matching on email didn't.
Small models need a rigid format. Early output was full of colons and stray punctuation until I forced short semicolon-separated items.
Check the output against your real data. Both models looked fine at a glance, and the difference only showed up when I compared them to my actual commit log.

Why Does Open Innovation Matter?

My commit history is my private working record: unreleased branches, half-finished fixes, repo names. With a closed API, every standup would send that to a server I don't control, and I'd be paying per call for a task I do daily. With an open-weight model, the whole pipeline runs on my laptop. No account, no API key, no cost, and it works with no wifi after the first model download.

Open weights also let me swap models by changing one line and compare 1.5B and 3B on my own repos rather than trusting a leaderboard. That comparison is how I caught the 1.5B's invented feature. A small quantized model turned out to be good enough for this job, and I could only learn that because I could run both.

The Lazy Payoff

Instead of digging through git log across three repos every morning, I run one command and wait about half a minute. It costs nothing per run, and I used it for my own updates this week.

"BillGuard AI: An Open-Model Invoice Auditor for Freelancers"

Aarya Shirsath — Thu, 15 Oct 2026 14:31:41 +0000

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

What I Built

Meet BillGuard AI, an invoice auditor designed for freelancers and small businesses that want to spend less time checking bills manually.

Invoices arrive as PDFs, screenshots, and photos. Important fields can be difficult to read, GSTINs can be mistyped, and subtotals, taxes, and totals don't always add up.

BillGuard AI extracts invoice details and checks them using deterministic Python rules.

It extracts:

Vendor name, invoice number, and date
GSTIN and expense category
Subtotal, tax, and final total

It then flags missing fields, invalid GSTIN formats, and arithmetic mismatches. Users can review the results in a dashboard and export them to CSV.

The goal is simple: make invoice review less tedious without pretending that AI extraction is automatically correct.

Demo

Live application: https://billguard-ai-ke9v.onrender.com/

Source code: https://github.com/Aarya0706/billguard-ai

The application is deployed on Render. The hosted demo uses a configured Gemini endpoint, so availability depends on the provider's API quota.

How I Built It

The application uses Python, FastAPI, PyMuPDF, Pillow, and a lightweight HTML/CSS/JavaScript dashboard.

The extraction pipeline works in two stages:

A vision model reads invoice images or PDF pages and returns structured fields.
Python normalizes the extracted values and applies deterministic validation rules.

I separated extraction from validation deliberately. A language model can misread a digit or confuse a subtotal with a final payable amount, so arithmetic checks should not depend on the model's own judgment.

The app supports different OpenAI-compatible vision endpoints. It is designed to run with the open-weight Qwen2.5-VL model through Ollama for local inference, or with a hosted provider when easier access is needed. The public deployment currently uses Gemini.

I also added automated tests for image processing, multi-page PDFs, malformed model responses, validation, rate limits, fallback models, and API errors. My latest local test run passed all 29 tests.

Why Does Open Innovation Matter?

Invoices can contain client names, addresses, tax identifiers, and financial details. Where that information is processed matters.

An open-weight model gives users a choice that a hosted-only application cannot offer: run inference on their own computer instead of sending every invoice to an external AI service.

With a local model configured through Ollama, invoice images can stay on the user's machine, and inference does not incur a per-request API charge after the model has been downloaded. The trade-off is that local models need storage and computing resources.

The hosted option makes the app easier to access, but invoice images are sent to the configured provider and usage limits can apply.

I also wanted to avoid locking the project to one model provider. A model can be replaced without redesigning the invoice validation pipeline.

For a small business, that flexibility matters: it offers a path toward privacy, predictable costs, and control over how the tool works.

What Could Someone Pay For?

The initial audience is freelancers, independent consultants, and small businesses that receive invoices regularly.

A potential paid version could offer larger batches, searchable invoice history, vendor-wise expense summaries, and accounting-friendly exports.

These are ideas to validate with users, not features or customer demand I am claiming to have proven yet.

Prize Categories

Best Use of Render — the application is deployed on Render, which hosts the public web app and its FastAPI backend.

Temple Heritage: an open-source AI yatra planner I took to Mahakaleshwar, Ujjain

Aarya Shirsath — Tue, 06 Oct 2026 08:19:29 +0000

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

Planning a pilgrimage usually means ten browser tabs, a group chat, and a map you can't read at the gate. I built Temple Heritage so the planning takes five minutes and the rest of the day is spent at the temple, not on your phone.

What I Built

Temple Heritage is a pilgrimage-planning app for people who want to actually go, not just scroll. You pick your preferences, and an AI planner builds a day-wise yatra (pilgrimage trip) with the stops ordered by an optimized route, so you spend less time traveling and more time there.

The screen is only the planning step. The output is a day-wise itinerary, a route map with a Google Maps handoff for navigation, festival countdowns, and nearby temples, all meant to be used on the road. Each temple has a voice-enabled Q&A assistant (English and Hindi), and a pilgrimage passport tracks the temples you've visited, which pushes you to go to the next one.

The planner runs on an open-weight model, OpenAI's gpt-oss-120b, so the AI core of the app is open and swappable.

It's for families, devotees, and heritage travelers who find trip planning a chore.

Demo

Live: https://templeheritage.me/
Code: https://github.com/Aarya0706/temple-heritage

I Took It Outside

I tested it on a real trip to Mahakaleshwar Temple in Ujjain, one of the 12 Jyotirlingas. I entered Ujjain, 2 days, and a temple-focused trip.

Instead of treating Mahakaleshwar as one more stop on a tourist checklist, the planner built the itinerary around the rhythm of a pilgrimage, including the early-morning Bhasma Aarti and the nearby temples.

The interesting part was the constraint. Bhasma Aarti starts at 4:00 AM, so dropping it randomly into a day plan would make everything after it unrealistic. The plan it gave me actually worked as a day: an early start, then a slower pace after.

That turned into a useful lesson for me. A planner shouldn't just generate places, it needs to generate a day that makes sense. Right now my validation catches invented temples, duplicates, and missing days, but it doesn't check timings. A time-aware layer for rituals like this is the next thing I want to build.

That's the problem Temple Heritage is trying to solve: turning a list of temples into a practical yatra.

How I Built It

Frontend/backend: Next.js + TypeScript + Supabase (auth, DB, migrations)
AI planner: OpenAI's gpt-oss-120b (open-weight) served through Groq, with schema validation to catch invented or duplicate temples
Temple Q&A: RAG chatbot with a custom TF-IDF retriever I wrote myself, so there are no embedding API calls and no vendor lock-in
Routing: nearest-neighbour + 2-opt route optimization (my own implementation, 23 tests) and Leaflet maps on OpenStreetMap
Recommendations: content-based, collaborative, and popularity signals combined
Quality: Vitest suite (140+ tests), ESLint, and CI on GitHub Actions that also deploys DB migrations

Why Does Open Innovation Matter?

Swappable models: the model is open-weight, though I currently run it on Groq's hosted service. It's a single constant in the code, so I can switch models or self-host later without rewriting the app.
Free to run: OpenStreetMap/Leaflet for maps and a self-written TF-IDF retriever for RAG keep the core features free per user. A pilgrimage app shouldn't need a subscription.
Transparent: the routing, retrieval, and recommendation logic is all readable code, not a black box.
What a closed API wouldn't give me: full control over retrieval and routing, and no per-call costs for maps or embeddings.