DEV Community: Yash Singh

Your Abandoned Repos Deserve an Ofrenda: Meet Graveshell

Yash Singh — Sat, 31 Oct 2026 16:34:43 +0000

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

What I Built

Graveshell is "a haunted terminal that whispers about your commands, and an ofrenda for the projects you let die." 👻

Every developer has a dark folder somewhere on their hard drive where unfinished ambitions go to rest: game prototypes, weekend micro-SaaS attempts, half-written CLI tools, and repos whose last commit was a hurried WIP: fix bug from two years ago. We usually feel guilty about them, or pretend they don't exist.

For the "Ghost in the Machine" theme (Halloween on October 31 and Día de los Muertos on November 1-2), I built around two traditions. Instead of hiding the ghosts in our machines, Graveshell welcomes them:

Mortimer, the terminal ghost 💀: a sarcastic sysadmin who died in a cold server room in 1987. He watches your terminal and reacts to "omens": failed commands, force-pushes, rm -rf, repeated frantic commands, and typos like gti instead of git. He answers with one eerie, darkly funny sentence.
The Graveyard 🕯️: run graveshell graveyard and it finds git repos untouched for 90+ days, then holds a small ofrenda for each one. You get a gravestone with the real data (birth date, date of death, days dead, commit count, last commit message), and only after that does Mortimer write a short epitaph. With --revive, it also shows uncommitted changes and the oldest TODO, as a nudge to bring a project back to life.

Everything runs locally through Ollama. No cloud APIs, no pip packages, and it works with Wi-Fi turned off.

Demo

Demo Video

The whole demo was recorded with Wi-Fi turned **off.

Here is a gravestone from the Graveyard:

💀 ENTERING THE GRAVEYARD (Dia de los Muertos Ofrenda)
Seeking git repositories resting for 90+ days in C:\Users\yash7...


         .-----------------------------------------------.
        /                   †  R.I.P.  †                  \
       |                                                   |
       |  Project:    MindForge                            |
       |  Born:       2026-06-28                           |
       |  Died:       2026-08-02                           |
       |  Resting:    90 days in darkness                  |
       |  Commits:    18 commits                           |
       |  Last words: "Production enhanc. push           " |
       |                                                   |
        \       🏵️   🕯️    OFRENDA DE REPOS    🕯️   🏵️  /
         '-----------------------------------------------'
       🕯️  Mortimer's Epitaph: "Forgotten code, a fleeting dream, born in darkness, died in haste, its purpose lost in the voidd, a mere whisper of what could have been."

And Mortimer reacting to a mistyped command:

.------------------------------------------------------------------------.
|  [!] MORTIMER'S POST-MORTEM
|  Command:     gti
|  Exit Code:   127 (Command Not Found)
|  Suggested:   git (typo fix)
|  Omen:        command not found (exit 127)
|
|  Mortimer's Diagnosis:
|     Another soul trapped in this forsaken terminal, waiting
|     for the inevitable reboot. The poor guy must be having
|     some kind of existential crisis, stuck in a loop of
|     terminal typing like
'------------------------------------------------------------------------'

Code

Github

Try it yourself (Windows PowerShell):

ollama pull llama3.2:1b
git clone https://github.com/Yash6012/Graveshell.git
cd Graveshell; python graveshell.py demo

How I Built It

Graveshell has strict constraints: Python 3 standard library only, a single core file (graveshell.py), and a local Ollama instance running the small open-weight llama3.2:1b model. There is nothing to pip install.

The key design decisions:

Plain Python first. The model never counts days, counts commits, or searches for files. Python and the local git CLI work out the facts, and the real evidence prints before any AI text appears.
Micro-prompts. The model sees at most 4 facts per call and writes ONE short sentence.
Redaction before inference. API keys, tokens, passwords, user:pass@ URLs and Bearer headers become [REDACTED] before anything reaches the model. Commands that start with a space are never sent.
Fail silent. If Ollama is down or too slow, Mortimer says nothing, so your prompt never hangs.
A tiny model on purpose. My laptop is weak, so I picked llama3.2:1b and kept prompts short to stay fast.
Built with an agent, then made my own. I used Google's Antigravity to scaffold the project, then tested it, learned how it works, and adapted it for Windows, including the PowerShell hook.

Why Does Open Innovation Matter?

For this kind of tool, open and local AI is not just an alternative to a cloud API. It is what makes the idea possible at all.

Privacy. A terminal is full of file paths, server names, half-finished ideas and the occasional pasted token. Sending every command to a third-party API would be a non-starter. With a local open-weight model, prompts only go to 127.0.0.1:11434 on my own machine.
It works offline. A haunted terminal that needs the internet isn't haunted, it's just an API client. Graveshell runs on a plane, in a train tunnel, or with Wi-Fi switched off for the demo.
Free per command. A ghost that can comment on any command you run would add up quickly on a metered API. Locally, each whisper costs nothing.
Swappable models. One environment variable changes the ghost's brain, for example GRAVESHELL_MODEL=mistral. I'm not tied to one vendor's model, pricing, or deprecation schedule.
No dependence on a service that can disappear. Graveshell exists to remember projects that died when their maker moved on. It would be ironic if Graveshell died because an API changed or shut down. Open weights and open code mean it keeps working as long as someone has a laptop.

SlipSense: a receipt sorter that never leaves your laptop

Yash Singh — Sun, 18 Oct 2026 18:28:50 +0000

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

What I Built

Every quarter, my brother, who runs a freelance graphic design studio in Indore loses an entire weekend to a shoe box of crumpled paper slips, WhatsApp photos, and email PDF invoices. They type every line into a spreadsheet by hand. They tried commercial expense apps, but deleted them immediately: those apps upload receipts to third-party cloud servers. Receipts carry home addresses, personal bank details, client names, and tax numbers. For privacy-conscious freelancers and small businesses, the cloud is a non-starter.

I built SlipSense to solve this. SlipSense is an open-source, local receipt sorter. You point it at a folder on your computer, and it extracts the data, validates the math, flags questionable rows, and organizes files into clean accounting categories. It runs entirely on your local machine using an open vision model in Ollama. Your files never touch an external server, and it works with Wi-Fi switched off.

The SlipSense dashboard: point to an input folder of receipts, confirm local Ollama status, and process in one click.

Who would pay, and how

The target audience is solo freelancers, tax consultants, and small shop owners who track business expenses for deductions. Cloud tools charge \$10 to \$30 every month for features a solo operator rarely uses.

The product model is a simple one-time desktop license or an annual "tax season pack" priced at INR 499 for standalone offline use.

To be completely clear: I have not charged anyone yet, and SlipSense currently has zero paying customers.

How it outputs data

SlipSense normalizes every document into nine standard columns:

Here is a real example from my test runs on receipt_01_amazon.jpg:

Status	Vendor	Sub Total	Tax	Total	Currency	Category	Date	Reason
OK	Amazon India	1101.69	197.31	1299.00	INR	Software	2024-09-12

On this receipt, the tax was split into 9% CGST (₹98.66) and 9% SGST (₹98.66). SlipSense extracted both tax lines, summed them into a single tax figure (₹197.31), verified that 1101.69 + 197.31 = 1299.00, matched the category from categories.yaml, and passed the validation check.

The review table showing extracted fields, currency tags, and automatic Needs-review flags.

Catching errors with human-in-the-loop review

A small local model will make mistakes. SlipSense assumes the model will fail on difficult images. Instead of blindly trusting model outputs, rule-based verification checks the numbers. If a vendor is missing, if total is zero or negative, if subtotal plus tax differs from the total by more than 1%, or if the model required a retry, the row is flagged Needs review with a plain-English reason.

Flagged rows automatically sort to the top of the table. Clicking any row opens an inspector showing the original receipt side-by-side with editable fields.

Side-by-side inspector card: examine the document while confirming or editing flagged fields.

When you export, SlipSense generates expenses.csv, copies each receipt into output/<Category>/YYYY-MM-DD_Vendor.ext without ever modifying your original files, and creates a category_summary.csv. The summary groups totals strictly by category and currency, never adding US Dollars to Indian Rupees.

Summary table aggregating expenses by category and currency, with grand totals.

Demo

Demo Video

The video shows SlipSense running on a laptop with Wi-Fi physically disconnected: selecting a folder of raw receipts, extracting structured data in real time, reviewing a flagged item in the inspector, and exporting the final spreadsheet and categorized folders.

Code

Github

How I Built It

Architecture

The entire pipeline runs locally in Python and Streamlit:

[Receipt Images & PDFs]
          │
          ▼
[image_prep.py] ── In-memory rendering (PyMuPDF at 110 DPI),
                   EXIF rotation fix (ImageOps.exif_transpose),
                   RGB conversion, in-memory resize (max_side <= 1000px),
                   JPEG quality 85 in io.BytesIO
          │
          ▼ (in-memory base64 string; zero disk temporary files)
      [Ollama] ── Model: qwen2.5vl:3b
                              JSON schema constraint via "format" parameter
          │
          ▼ (raw JSON response)
[Pydantic Validation] ── Coerce numeric strings, currency symbols, nullable fields
          │
          ▼
[validation.py] ── Deterministic checks: 1% arithmetic tolerance, future dates,
                   category matching, duplicate detection, tax derivation
          │
          ▼
[Streamlit UI (app.py)] ── Interactive review table, inspector card, inline edits
          │
          ▼
[exporter.py] ── expenses.csv, category_summary.csv,
                 safe copy into output/<Category>/YYYY-MM-DD_Vendor.ext

The stack

Language & UI: Python 3.13, Streamlit
Local Vision Model: qwen2.5vl:3b running in Ollama on localhost:11434
Image & Document Processing: Pillow (PIL), PyMuPDF (fitz)
Data Validation & Parsing: Pydantic v2, PyYAML, Pandas

Image preparation settings

All image pre-processing is configured in config.yaml with zero hardcoded parameters:

max_side: 1000 pixels (longest dimension downscaled in memory; smaller images are never enlarged)
jpeg_quality: 85 (compressed in-memory via io.BytesIO)
pdf_dpi: 110 (rendered directly from vector page to raster image)

User originals are never touched, and no temporary resized images are written to disk.

Measured benchmark results

I wrote a standalone benchmark script (benchmark_sizes.py) that evaluates qwen2.5vl:3b on the same test receipts across three different resolutions (max_side = 1400, 1000, 800).

Here are the real measured numbers from benchmark_report.md:

max_side	Average seconds per file	Files flagged "Needs review"	Total-field accuracy
1400	36.50s	0 / 5	100.0% (5/5)
1000	8.57s	0 / 5	100.0% (5/5)
800	9.28s	0 / 5	100.0% (5/5)

A failure I hit

When testing resolution scaling, I initially tried sending larger images (max_side = 1400) believing higher resolution would yield better field extraction.

Instead, I hit a massive latency cliff. Vision transformers tokenize images into fixed-size visual patches. At 1400px, complex receipts like receipt_03_invoice_consulting.jpg and receipt_04_aws.jpg caused token counts to swell, spiking latency from 8.5 seconds up to 56.21s and 57.37s per document on my machine. Worse, accuracy did not improve by a single percent: max_side = 1000 achieved identical 100% total-field accuracy at 8.57s average—over 4.25x faster. Downscaling to 1000px proved essential for running locally without memory exhaustion.

Four design decisions I defend

Rule-based code decides trust, not model confidence scores: Vision models frequently hallucinate high confidence on wrong numbers. My validation code checks arithmetic (subtotal + tax == total), verifies date boundaries, and flags discrepancies deterministically.
The model never guesses: If a field is illegible, the prompt instructs the model to output null. SlipSense then flags the row for human review instead of fabricating numbers.
Original files are sacred: SlipSense only reads originals. Copies are placed into category folders with sanitized names, and collision counters prevent overwrites.
Needs-review rows sort to the top: In a folder of 50 receipts, a user should not have to hunt for the three that need human attention.

Why Does Open Innovation Matter?

Absolute privacy and offline reliability: Receipt data contains bank details, vendor contacts, and private purchases. With open models and local runtimes like Ollama, data never leaves the device. The application functions in a remote cabin or on an airplane with Wi-Fi switched off.
Zero marginal cost: Closed vision APIs charge per page or per API call ([CHECK CURRENT PRICING, e.g. $0.01 to $0.05 per document]). For an irregular freelancer processing 30 receipts one month and none the next, subscription fees and API meters add friction. An open model running locally costs zero cents per file.
Model independence and longevity: Closed cloud APIs deprecate endpoints, adjust system prompts, and change rate limits without warning. In SlipSense, switching to another model requires changing one line in config.yaml (model_name: "qwen2.5vl:3b"). The software remains operational ten years from now on local hardware.
Inspectable, customizable taxonomy: Business categories vary across countries and industries. Instead of opaque cloud categories, SlipSense uses an open categories.yaml and examples.yaml that any user can adapt to their chart of accounts.

The honest counterweight

A closed frontier model (like GPT-4o or Gemini 1.5 Pro) running on cloud TPU clusters would be faster in raw throughput and better at deciphering crumpled, handwritten cursive or faded thermal receipts. A 3B local model requires decent CPU/RAM, takes about 8.5 seconds per document on a laptop, and cannot reliably read illegible handwriting. I chose the local model anyway because for accounting documents, absolute data confidentiality outweighs cloud speed.

My Agent Session

I built SlipSense pairing with Google Antigravity, Google AI Studio an agentic AI coding environment. Antigravity handled file generation, wrote comprehensive pytest suites, ran background CLI commands to measure model latency, and helped refine image preparation logic.

My First User

To be transparent: SlipSense currently has no paying customers, and I have not charged anyone.

I have reached out to several local shopkeepers and independent freelancers in my neighborhood to get early feedback on the offline workflow.

Prize Categories

I’m a backend developer, so ML was new ground for me. Tinker let me write a fine-tuning loop in plain Python without wrestling with GPUs, which meant I could actually focus on learning. I fine-tuned [MODEL] on [N] synthetic receipts and compared it with the base model: [REAL RESULT]. I used synthetic data only, since SlipSense exists to keep real receipts on the user’s laptop, and the final model still runs locally through Ollama.

Intro

Yash Singh — Wed, 14 Oct 2026 06:53:36 +0000

Hi, I'm Yash Singh!

I'm a software and hardware enthusiast working in the world of Internet of Things. I love bridging the physical and digital worlds—connecting embedded systems, smart devices, and cloud architecture to build intelligent, connected solutions.

I joined DEV to share my journey, document my projects, and connect with other engineers passionate about IoT, hardware, and scalable backend systems.