DEV Community: Sneha Choudhary

Ghost Shell: The Terminal Ghost That Stops You From Wrecking Your Work

Sneha Choudhary — Sat, 31 Oct 2026 05:12:25 +0000

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

What I Built

Ghost Shell is a ghost that lives inside your terminal.

Every student remembers the first time a command failed and the error looked like a foreign language. Worse, beginners paste commands from the internet without understanding them, and one wrong rm -rf or git reset --hard can wipe out a whole project.

So I gave my terminal a ghost:

When a command fails, a spooky sound plays. Each mistake has its own sound: a creaky door for "command not found", rattling chains for "permission denied", a wail for a syntax error, footsteps for a missing file. The ghost then says a short spooky line and, under it, gives the real fix in plain words.
When a command is dangerous, the ghost stops it before it runs, explains what you would lose, and asks you to type yes to continue.
When you fix your mistake, a soft chime plays.

For example:

👻 The terminal graveyard echoes in silence... pythno has no soul in this realm.
Fix: Check for typos in pythno or install it via your package manager.

My take on the theme is a haunted machine that haunts you for your own good. The spooky layer is the fun part, but it never hides the answer, so a beginner learns something from every mistake.

Demo

Code

snehach03 / ghost_terminal

👻 Ghost Shell

::: {align="center"}

       .-.
      (o o) boo!
      | O \
       \   \
        `~~~'

A haunted terminal assistant for students.

:::

Ghost Shell is a lightweight terminal guardian designed to help students learn the command line without fear. It watches commands, explains common errors in plain English with a little spooky atmosphere, plays procedural sound effects, and checks potentially destructive commands against deterministic safety rules.

🛑 Dangerous-command checks: identifies configured destructive command patterns and explains the potential impact before execution.
🔊 Procedural sound effects: generates audio cues for errors, alerts, and successful fixes.
👻 Error explanations: combines spooky lore with a clearly labelled, actionable Fix: instruction.
⚡ Rule-first responses: common errors can be handled by built-in templates without calling an AI model.
🔒 Local-first design: everyday rule-based features work locally. An optional local model can be used as a fallback for unusual errors.

Note: Feature behaviour depends on the…

View on GitHub

How I Built It

Shell hooks for PowerShell, bash and zsh catch each command and its exit code, and check commands against the danger rules before they run.
Rules come first. Common errors (command not found, permission denied, file not found, syntax error) are explained instantly by built-in templates, so most mistakes never need an AI model.
Dangerous-command detection is rule-based on purpose. A pattern list covers rm -rf, git reset --hard, git clean -fd, git push --force, chmod -R 777, dd, mkfs, DROP DATABASE and fork bombs. I did not let a model decide what is dangerous, because a small model can misjudge risk and a pattern list cannot. A human always confirms before anything risky runs.
A small open-weight model handles the unusual cases. For long stack traces and unfamiliar tools, Ghost Shell asks Qwen2.5-0.5B-Instruct (a ~400 MB quantized GGUF file), served locally by llama.cpp's llama-server. The Python client calls it over localhost using only the standard library. If the server isn't running, the rule-based features keep working.
Sounds are generated with Python's built-in wave and math modules, so there are no licensing problems and no audio libraries. Users can swap in their own.
Explanations are cached, so a repeated error is instant.
I used Google AI Studio as my coding assistant to build the project from a detailed spec I wrote, then tested it myself.

I first considered Ollama, but it was too heavy for my laptop. Moving to llama.cpp with a tiny model, and letting rules do the routine work, made the tool lighter and faster, and I think it is a better design.

Why Does Open Innovation Matter?

Whatever a student types into a terminal can include file names, project names, and sometimes passwords or tokens by mistake. I didn't want any of that sent to a server.

It works offline. The ghost still haunts you with the Wi-Fi off, which suits a hostel or lab with bad internet.
Nothing you type leaves your machine. The model server runs on localhost, which wouldn't be true if explanations came from a closed API.
It costs nothing to run. No account, no API key, no per-request bill.
The model is swappable. Drop another GGUF model in the models/ folder and change one line in config.json, so the project isn't locked to a service that might change its pricing or disappear.
It runs on a plain laptop. A 0.5B model needs no GPU, so an ordinary student machine can use it.

Tomorrow's Tray

Sneha Choudhary — Sat, 24 Oct 2026 05:59:11 +0000

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

What I Built

Every night, a baker closes the shop and guesses: how many croissants tomorrow?

Guess too low and the 11am customers find an empty tray. Guess too high and
the leftovers go in the bin. Most small bakeries do this from gut feeling.

Tomorrow's Tray takes the sales export from your till (a plain CSV) and
produces tomorrow's prep list: how many of each item to bake, with a range
instead of a single number, plus a one-line reason for each. The baker can
override any number. The tool suggests, the baker decides.

The part I care most about: a till counts sales, not demand. If the
croissants sold out at 10:40, the data says "36 sold", but real demand was
higher. Forecasting from that number quietly teaches your model to
under-bake. Tomorrow’s Tray treats sold-out days as censored observations: it estimates the demand that was missed as a range, using a Tobit-style conditional expectation blended with a diurnal arrival-curve correction, and never reports it below what actually sold.

The lazy part: the baker stops doing the nightly guessing and mental maths.

Demo

Live app: https://week-3-1-6qet.onrender.com/

The first load can take 30-60 seconds because the free instance wakes up from sleep.

Code

https://github.com/snehach03/week_3

How I Built It

I built Tomorrow's Tray with Google's Antigravity as my coding agent. My brief
had one priority: a smaller, scientifically honest working product is better
than an elaborate mockup.

Stack: React, TypeScript, Vite, Tailwind and Recharts on the front end;
Python, FastAPI, pandas and SQLAlchemy with SQLite on the back end. State is
stored in SQLite, not in the browser.

1. Censored demand (the core idea). Dividing sales by the fraction of the
day that has passed fails, because bakery traffic is front-loaded: most
customers come in the morning. Instead, the correction module blends two
estimates:

a Tobit-style conditional expectation: given that comparable uncensored days look roughly normal, it estimates what demand was, knowing it was at least what sold;
a diurnal correction that uses an assumed Beta-shaped customer-arrival curve between 07:00 and 17:00.

The result is never lower than what actually sold, is reported as a range, and
is labelled "limited data" when there are fewer than two comparable
uncensored days.

2. Forecasting. For each item the app forecasts tomorrow's demand with a
P10-P90 range, using empirical quantile intervals. It supports a
same-weekday-last-week baseline, a four-week same-weekday average, and a
Random Forest with lag and momentum features. A service-level setting (70, 85
or 95%) controls how much buffer goes into the suggested quantity.
TabPFN is included as an optional adapter.

3. Explanations. The backend computes the evidence and can pass it to a
local Gemma model through Ollama to turn it into one sentence. If Ollama is
not running, a deterministic template writes the explanation instead, so
nothing depends on a model being available.

4. The baker decides. Every suggested quantity can be overridden with a
note. The AI suggestion is stored next to the baker's final number and never
overwritten. The prep list exports to CSV for the kitchen.

5. Evaluation. The app has a Model Performance page with an
expanding-window backtest (the model never sees future data). It compares the
models on MAE, WAPE and RMSE, reports interval coverage, and evaluates
uncensored days separately, because sales on a sold-out day are not complete
ground truth. The repo includes 22 unit and integration tests covering CSV
validation, censored demand, forecasting, backtesting and the API.

What this does not claim:

It is a forecast, not a guarantee. The baker's judgement stays final.
The demo data is simulated, not from a real shop. For that reason I am not quoting headline accuracy numbers in this post: on simulated data they would say more about my simulator than about real bakeries.
The arrival curve in the correction is an assumption, not something learned from a real bakery's till.
I have not tested it with a real bakery yet.

Why Does Open Innovation Matter?

A bakery's sales history is private business data. Tomorrow's Tray is designed
to run entirely on the baker's own machine: the forecasting models are open
source (scikit-learn, with TabPFN as an optional open-weight adapter), the
optional explanation model is local Gemma through Ollama, and no API key or
subscription is required.

The code is MIT-licensed, so a bakery, or a developer helping one, can read
how the forecast is built, change the models, or fix the assumptions.

One honest caveat: the live demo is hosted on Render. The "your data stays
with you" benefit applies when you run the project locally from the repo.

My Agent Session

I used two prompts with Antigravity. The first was a build brief: the product,
the censored-demand module, chronological backtesting, tests, and an explicit
rule not to claim any test passed unless it was actually run, and not to
claim the model beats a baseline unless the backtest shows it.

The second set the agent's permissions. It had full autonomy inside the
project folder to install dependencies, write code, run tests and debug
without asking me each time. It was not allowed to touch anything outside the
folder (system settings, global installs, other projects), use admin rights,
or upload my files or data to external services. Deleting important data,
publishing or deploying, paid services, and sending private data to
third-party APIs still needed my approval.

Prize Categories

Best Use of Render: the app is deployed on Render at https://week-3-1-6qet.onrender.com/

MomentSort — AI-Powered Wedding Photo Organizer

Sneha Choudhary — Fri, 16 Oct 2026 20:43:18 +0000

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

What I Built

MomentSort AI-Powered Wedding Photo Organizer

Wedding photographers often return from an event with thousands of photos. Finding a specific moment—like a bride's portrait, a groom's candid shot, or wedding decor can be time-consuming when everything is scattered across folders.

MomentSort is an AI-powered photo organization project designed to make searching and organizing wedding memories easier. It combines image embeddings, similarity-based search, blur detection, and photo grouping to help photographers find relevant images and organize event moments.

The goal is simple: spend less time manually browsing photos and more time delivering beautiful memories to clients.

Potential users include wedding photographers, photography studios, event photographers, and anyone managing large collections of event photos.

Demo

Live Demo: https://week2-project-1.onrender.com

Explore the API documentation and try the available demo search functionality.

The hosted version currently runs in demo mode. Full folder-based analysis is intended to run locally because it requires access to the user's photo folders and a heavier AI model.

Code

GitHub Repository: https://github.com/snehach03/week2_project

The repository contains the backend, API endpoints, search functionality, and the photo-analysis pipeline.

How I Built It

I built MomentSort using Python and FastAPI, with a focus on making AI-powered photo organization practical.

The project brings together:

FastAPI for the backend and API endpoints.

SigLIP image embeddings for representing images as vectors and enabling similarity-based search.

NumPy for vector operations and similarity calculations.

OpenCV for blur detection and image-quality checks.

Photo grouping and duplicate detection to help organize related images and identify similar shots.

Render for hosting a lightweight demo of the application.

The project separates the lightweight hosted demo from the heavier local analysis pipeline. This allows users to explore the available search functionality online without requiring the full AI model to run on a memory-constrained hosting service.

Why Does Open Innovation Matter?

Open innovation made it possible to experiment with AI-powered image understanding without building an entire computer vision stack from scratch.

Open-source tools and model ecosystems gave me access to image embeddings, vector operations, image-processing libraries, and backend frameworks that I could combine into a practical application.

It also helped me understand the real-world engineering trade-offs behind AI products: model size, memory constraints, deployment environments, and the difference between a local workflow and a hosted service.

For me, the biggest lesson is that building with AI is not just about choosing a model. It is about making the complete system useful, accessible, and reliable.

Outside.exe - The Real World Is the Game Map 🌿🎮

Sneha Choudhary — Fri, 09 Oct 2026 17:06:44 +0000

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

What I Built

Outside.exe — The Real World Is the Game Map 🌿🎮

What if going outside felt like playing a game?

That question inspired me to build Outside.exe, an AI-powered real-world adventure game that turns ordinary surroundings into opportunities for exploration.

Instead of giving people another reason to stay on their phones, Outside.exe encourages them to step away from their screens and complete physical-world quests.

Users choose their available time, energy level, mood, and environment. Based on this context, the application generates personalized adventure missions.

For example:

Mission 1: Walk for five minutes without headphones.

Mission 2: Find something you've walked past many times but never actually noticed.

Mission 3: Find something that is moving, something making a sound, and something that looks out of place.

Once an adventure starts, users are encouraged to put their phones away and explore the real world.

When they return, they can describe what they encountered. These observations can then inform the next mission, turning the adventure into an evolving experience rather than a fixed checklist.

The core idea is simple:

Use AI to make the real world more interesting, not the screen more addictive.

Outside.exe is designed for people who want to break their routines, explore their surroundings, spend less time on their phones, and rediscover the little things they usually overlook.

The goal isn't to maximize screen time. It's to make the screen the shortest part of the experience.

Demo

🌐 Live Demo: https://outside-exe-4.onrender.com/

Try the application and start your own real-world adventure.

The project is designed around a simple loop:

Configure → Explore → Observe → Reflect → Explore Again

Code

💻 GitHub Repository: https://github.com/snehach03/outside.exe

The source code for Outside.exe is available in the repository.

How I Built It

I built Outside.exe as a web application using Next.js, React, TypeScript, and Node.js.

The application follows an adventure flow that connects user preferences with real-world missions and subsequent check-ins.

The Adventure Loop

1. Adventure Setup

Users provide information such as their available time, energy level, mood, and environment.

2. Mission Generation

The AI uses the available context to create an adventure with physical-world challenges.

3. Real-World Exploration

Users put their phones away and complete their missions in the world around them.

4. Check-in and Adaptation

After returning, users describe what they experienced. Their observations can inform the next mission, making the experience more personal and dynamic.

AI Integration

I used Ollama as the local runtime for an open-weight AI model.

The goal of this integration is to use an open-weight model to generate adventure missions and adapt challenges to the user's context and observations, rather than making a closed cloud API the only possible foundation.

Ollama provides a way to run models locally, giving developers greater control over the inference environment and the freedom to experiment with different supported models.

I used Claude Code as my AI coding agent during development. It helped me implement features, debug Next.js and TypeScript build errors, and prepare the application for deployment.

The web application is deployed on Render.

Why Does Open Innovation Matter?

AI doesn't always have to keep people staring at screens.

For Outside.exe, I wanted to explore the opposite: using AI to encourage curiosity, movement, and interaction with the physical world.

Open-weight models and tools such as Ollama make it possible to experiment with local inference, explore different models, and have more control over how an AI-powered application behaves.

This matters because developers should have the freedom to understand, adapt, and experiment with the technology behind their applications.

For a project like Outside.exe, local inference also offers the possibility of keeping user interactions within a locally controlled environment when the application is configured to run that way.

The larger idea behind the project is to change how we think about AI-powered experiences.

Instead of:

AI → More Screen Time

Outside.exe explores:

AI → Physical Challenge → Exploration → Observation → New Challenge

I want AI to become a bridge between the digital and physical worlds, helping people notice more, explore more, and spend less time passively consuming content.

The best outcome is not a user spending hours inside Outside.exe.

It's a user closing the app, stepping outside, and discovering something new.

Prize Categories

Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass

devchallenge #hf26challenge

DEV Community: Sneha Choudhary

Ghost Shell: The Terminal Ghost That Stops You From Wrecking Your Work

What I Built

Demo

Code

snehach03 / ghost_terminal

👻 Ghost Shell

How I Built It

Why Does Open Innovation Matter?

Tomorrow's Tray

What I Built

Demo

Code

How I Built It

Why Does Open Innovation Matter?

My Agent Session

Prize Categories

MomentSort — AI-Powered Wedding Photo Organizer

Outside.exe - The Real World Is the Game Map 🌿🎮

What I Built

Demo

Code

How I Built It

The Adventure Loop

AI Integration

Why Does Open Innovation Matter?

Prize Categories

Tags

devchallenge #hf26challenge