DEV Community: Shristi Sharma

👻🎬Miedocuentista: a fully local AI that turns your photos into haunted stories, film scripts and novels📜🪶

Shristi Sharma — Sat, 31 Oct 2026 19:00:05 +0000

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

What I Built

Miedocuentista ("fear-teller") is a spooky storytelling machine that runs entirely on my laptop. You feed it images one at a time and it writes the story frame by frame: a short film script, a film story, or a novel with one chapter per image.

How it works in one breath: a small vision model looks at each image and lists what it sees (objects, setting, mood), I can correct that list and add my own twists, and a small language model writes the next scene while a rolling "story memory" keeps the plot, characters and open threads alive between scenes. After the final image, I run a Final AI Story Editor that reads the whole story, looks for plot holes and timeline problems, and rewrites every scene so they connect, trying to keep the storyline intact.

How I interpret the theme. The ghost in this machine isn't hiding inside the model. It is what the machine sees in your photographs (every frame is treated as a haunted scene) and what it remembers between scenes: the story memory literally haunts each new scene with everything that came before. It has a Halloween interface, a horror default, and a Día de los Muertos tone for warmer, remembrance-style stories.

What inspired it. It started from one of the challenge's own ideas, a ghost story generator. My first version was simple: one photo in, one ghost story out, using a small vision model and a small language model on my laptop. But one photo only gives you one scene, and stories, films and novels are made of many frames. So I extended it into a frame-by-frame studio where every new image continues the story. I also wanted to build the front end of a future AI video workflow: storyboard images go in, a structured script comes out (visuals, sound, dialogue, transitions) that other open-source tools could later turn into video. And I wanted all of it to run on my own machine, so my photos and stories never leave it.

Why a pipeline, not just a toy. The script format separates VISUAL, SOUND, dialogue and TRANSITION on purpose, and every scene is stored as structured JSON. My longer-term goal is to feed this into open-source image/video and text-to-speech workflows (storyboard in, script out, shots next). That hand-off is not built yet; today it produces the script, story or novel and exports .txt/.md.

Demo

Screenshots, in the order of the workflow:

Code

shristi005 / Miedocuentista

Feed the spirits one frame at a time. They write the film, the script, the novel.

👻 Miedocuentista

A fully local, open-source AI story studio that turns a sequence of images into a short story, a film script or a novel, one frame at a time.

Miedo (fear) + cuentista (storyteller): the fear-teller. Built for the Hacktoberfest Open-Source AI Challenge, Week 4: Ghost in the Machine.

Everything runs on your own computer through Ollama. No cloud, no API key, no cost, and your images never leave your machine.

👻 Miedocuentista

View on GitHub

The outputs from my test runs (problems included) are in the tested_outputs folder of the repo.

Run it yourself (needs Ollama and Node.js 18+):

ollama pull moondream
ollama pull qwen2.5:3b
git clone https://github.com/shristi005/Miedocuentista.git
cd Miedocuentista/backend
npm start

Then open http://localhost:3002. There is no npm install step; the backend has zero dependencies.

How I Built It

Open models (via Ollama, all local):

moondream (about 1.7 GB, open weights): the "eyes". For each frame it answers four short questions (caption, objects, setting, mood). Small vision models follow short questions far better than one long prompt.
qwen2.5:3b (about 1.9 GB, open weights): the "writer", the "memory keeper" and the "editor".

App: Node.js backend with zero npm dependencies, plain HTML/CSS/JS frontend, and one JSON file per project. Frontend and backend are separate folders.

The parts I'm proudest of:

Rolling story memory. A 3B model on a small GPU can't re-read a novel for every scene. After each scene, the model merges the old memory with the new scene into a note of about 140 words (characters, setting, events, open threads). The note stays the same size however long the story gets, and only the previous scene's ending is passed word for word.
Regenerate / undo that restores the story memory. Each scene saves the memory from before it, so regenerating or undoing the last scene brings back the exact earlier state.
Final AI Story Editor. Pass 1 reads the complete story and writes an edit report (canon, plot holes, timeline errors, repetition, weak transitions, per-scene fixes). Pass 2 rewrites each scene using that report plus the neighbouring scenes. The original is always kept, with an Edited/Original toggle.
Human in the loop. The vision model makes mistakes, so every frame's caption and element chips are editable before they shape the story.

Challenges I Hit (and Why I Think They Happen)

I tested with a three-frame lighthouse story: a boat and pier, a stone archway ringed with red roses and an urn, and a keeper's room with a journal. The pipeline worked end to end (image to elements to scene to memory to next scene to editor), but a 3B model on a 4 GB GPU has real limits. I'd rather show them than hide them. The causes below are my best diagnosis from reading the outputs and my own prompts, not proven facts.

Problem I saw	What it looked like	Likely cause	Planned fix
Copy-pasting earlier text	The same paragraphs ("The room spun, making her dizzy for a moment…", "The handprint on the urn matched the others…") show up in all three chapters	My prompt passes the last ~1,200 characters of the previous scene word for word. Small models tend to copy what is sitting in their context, and I set no repetition penalty	Pass a one-line summary of the last beat instead of raw text; set a repeat penalty; detect duplicated sentences and regenerate
The story stalls and loops	Chapters keep re-describing the lantern, the midnight, the room and the handprint instead of moving on	I tell the writer to use every visible element, neighbouring frames overlap, and the model has no plan for what NEW thing happens	A "beat planning" step: decide one new event and one new piece of information, then write from that plan
Memory feeds on itself	Repetition gets worse in later chapters, and the timeline resets (she arrives at the dock again)	The story memory is summarised by the same small model from text that is already repetitive, so the repetition is baked into the memory. There is no location/time tracking	Structured memory (character sheet, event list, current place and time), facts the user can pin, and de-duplication before summarising
Headings and numbering ignored	Two blocks labelled "Chapter 2" and a third with no heading; chapter titles reuse the book's title	I ask the model to write the heading itself, and 3B models follow formatting loosely	The app inserts the chapter number; a separate tiny call writes a new chapter title
Prompt wording leaks into the prose	Phrases like "the journal from the previous scene" appear inside the story	Labels in my prompt (PREVIOUS SCENE, reader-added elements) get echoed	Rename labels, clean leaked phrases after generation, add a worked example
Script mode leaks its template	`NAME:` printed literally, `CUT TO / FADE OUT / SMASH CUT` copied as-is, the prompt's input block echoed	I used placeholders in the format instructions and the model copied them	Replace placeholders with one concrete example scene; strip stray labels
The Final Editor can't fix it	The edited version still has repeated passages	The editor is the same small model that wrote the problems, so it cannot reliably spot them	A deterministic de-duplication pass first; a larger model for the editor only
Vision mistakes	The 1.7 GB vision model sometimes misses or invents objects	Tiny model	Already mitigated: every caption and chip is editable before it shapes the story. Next: a stronger vision model

What this taught me. Small local models are good at structure and weak at long, coherent prose. Most of what went wrong is engineering around the model (what I put in its context, what I let it decide, what I check afterwards), not a flaw in the idea. The rolling memory and two-pass editor are my first answer to that; the table above is the second round.

Future Improvements

Quality guardrails: a repetition score for every scene, automatic regeneration when a scene copies earlier text, and a "must change something" rule for each scene.
Planning before writing: generate a short beat (new event, new information, emotional turn) from the story memory and the frame, then write the scene from that beat.
Better memory: structured JSON memory with a character sheet, timeline and open threads, plus facts the author can pin so names and relationships never drift.
Stricter formats: the app owns chapter numbers and scene headings; script output is cleaned and validated.
Bigger or better models: because the models are environment variables, a 7B or 8B model (on a machine with more VRAM) can be dropped in. I want to benchmark a few open models side by side on the same frames.
In-browser editing of any scene, and a side-by-side diff between original and edited versions.
Video-workflow hand-off: export each scene as a shot list (VISUAL, SOUND, dialogue, duration) so open-source image/video and text-to-speech tools can pick it up. Not built yet.
A Día de los Muertos "ofrenda" mode: remembrance stories from old family photos, kept fully on the owner's machine. Today the Día de los Muertos option is only a tone setting.

How It Can Be Used

Today, Miedocuentista is best treated as a first-draft and idea engine, not a finished-story generator. You get structure and momentum quickly, then you edit.

Short films and YouTube videos: drop in storyboard frames or concept art, get a scene-by-scene script with visuals, sound and dialogue to rewrite. Later, the same structure is meant to feed AI video workflows.
Novel and short-story outlines: turn a mood board or a folder of reference images into chapters to react to.
Game and world-building: turn level screenshots or location art into lore and quest text.
Classrooms and writing groups: the same photos, different frames, different stories; compare and discuss.
Private projects: because everything is local, it is suitable for personal photos and unreleased art.

How: (1) pick short film, feature film or novel; (2) choose script or story; (3) add your frames one by one and correct the elements; (4) mark the last frame; (5) run the Final Editor; (6) export .txt or .md and finish by hand.

Why Does Open Innovation Matter?

Your photos stay yours. Stories get built from personal images: old family photos, sketches, unreleased concept art. With local open-weight models, none of it is uploaded anywhere.
It works with the lights (and the internet) off. No API key, no rate limit, no per-token bill. The UI even avoids external fonts and CDNs.
It's not locked inside a service that might disappear. Projects are plain JSON files I own. If a hosted API changes its pricing or shuts down, my stories and my workflow survive.
Swappable models. The vision and story models are environment variables, so another open model can be tried without touching the code, and a stronger machine should give better stories. (So far I have only tested moondream and qwen2.5:3b.)
It made a tiny-model design possible. The rolling memory and two-pass editor exist because I had to make a 3B model on a 4 GB GPU work. A closed API with a huge context window would have hidden that problem instead of letting me solve it.
Free to run, which matters for students and indie creators.

The Spirit of It

I gave it three images: a boat with a lantern at a lighthouse pier, a stone archway ringed with red roses, and a keeper's room with a journal. Out of those three photos, with no plot from me, it wrote a novel in my first test run whose final chapter ends on a twist I did not plan: the light the heroine had been chasing for fifteen years was her missing brother all along.

The outputs from my test runs (problems included) are in the tested_outputs folder:

Novel output (3 chapters)
Short film script output (3 scenes; the weakest result, see the Challenges section)
The three input frame images

ClaimReady: a local-AI claims workbench for hospital front desks

Shristi Sharma — Mon, 19 Oct 2026 05:31:03 +0000

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

What I Built

ClaimReady is a claims workbench for hospital front-desk and billing staff. It puts three jobs in one place: checking a claim before it goes out, tracking the insurer's follow-up questions, and reconciling what the insurer actually paid.

Here is how it works for Rachael, a front-desk staff member, and Ritu, a patient she is helping:

Claim Check. Rachael uploads Ritu's claim form, hospital bill and discharge summary. ClaimReady flags anything that may need attention, such as a missing document or an amount that differs between files, and shows the exact text from each file. Rachael checks the findings, gets anything missing, and sends the claim to the insurer herself.
Query Desk. The insurer asks for the discharge summary and the admission and discharge dates. Rachael records the request and its due date. ClaimReady finds the matching lines in the uploaded documents, shows which file each came from, notes that the summary is missing, and prepares a draft reply. Rachael edits it, sends it herself, and updates the status (Open, Waiting for documents, Ready to review, Responded).
Payment Tracking. The insurer pays ₹40,000 on a ₹45,000 claim. Rachael records the claimed, approved and received amounts. ClaimReady shows the ₹5,000 difference and keeps it visible until she records what explains it.

Who would pay: small and mid-size hospitals and clinics whose front-desk or billing staff chase claims across folders, spreadsheets and messages. The cost of that is missed documents, forgotten insurer deadlines and shortfalls nobody explains. I have not tested pricing with a real customer yet, so I'm not claiming a price or a savings figure.

What it does not do: it does not decide coverage, approve or reject claims, send claims or replies, or connect to insurers. Staff stay in charge of every decision.

Demo

Code

shristi005 / ClaimReady

ClaimReady

A claims workbench for hospital front-desk and billing teams. ClaimReady brings claim checks, insurer follow-up, and payment reconciliation into one place.

ClaimReady is a hackathon prototype that supports staff review. It does not decide coverage, approve or reject claims, or send claims or replies to insurers.

The problem

Staff helping with health insurance claims often need to coordinate forms, bills, insurer messages, deadlines, and payment records. When that work is scattered across folders, spreadsheets, and messages, it is easy to miss a missing document, forget a response deadline, or overlook a payment difference.

ClaimReady gives staff one workflow to review a claim, manage insurer questions, and account for settlement amounts.

Who it is for

The prototype is designed for hospital front-desk and billing staff who help patients prepare and follow up on insurance claims.

Features

Claim Check — review a claim before submission

Staff upload documents such as a…

View on GitHub

Fictional sample claims are in backend/eval/testClaims/ and demo-assets/, so you can try it without any real data.

How I Built It

Frontend: React + Vite.
Backend: Node + Express, with a local SQLite database and built-in accounts, hospital workspaces and roles. No cloud database or external login service is needed.
Open-source AI: an open-weight model, Qwen2.5 3B, running locally through Ollama. An optional Groq provider exists, but it is off by default and sends text to a hosted service.
Document reading: text is read from PDFs and OCR handles images. Regular matching rules run first.

What the model does, exactly:

Feature	Where the model is used
Claim Check	Only when the rules cannot find a required field or the bill's line items. The model's answer must include a quote that appears in the document, otherwise it is rejected and the item goes to "Check manually".
Query Desk	Not used. Evidence search and draft replies come from matching logic and a template.
Payment Tracking	Reads an uploaded remittance advice (PDF, PNG or JPG) and suggests the settlement amounts and any stated deductions, with the supporting text. Nothing is saved until staff review it and save.

All comparisons, such as amounts, dates, IDs and the settlement balance, are plain code. The model reads messy text. It does not judge anything.

Results on my own test set (9 fictional claim packets with planted errors, qwen2.5:3b on a Windows laptop with a GTX 1650 and 4 GB of GPU memory, run with npm run eval):

Planted issues caught	False alerts	Items sent to manual check	Average time per packet
9 of 9	0	4	2.3 s

The 4 manual checks all came from the two packets written in unusual wording. The model could not confirm a field, so the app asked a person instead of guessing. These packets are small, text-based and made by me, so this is not a real-world accuracy benchmark. Real hospital paperwork will be messier.

Why Does Open Innovation Matter?

Documents stay on the machine. Claim papers contain sensitive health and financial details. With Ollama, the model runs on the computer hosting the app, so the AI step needs no third-party model API.
No per-document cost. A small clinic can run it without paying for every claim it checks. A 3B model runs fully on a 4 GB laptop GPU, as ollama ps showed on my machine.
Control over behaviour. Because I run the model myself, I could force structured JSON output, require a quote for every extracted value, reject answers that are not in the document, and swap the model by changing one setting.
Where it was weaker. The small model missed fields on unusual wording, and early on it reformatted dates in ways my first checker rejected. I fixed the checker, and the design now sends anything uncertain to a human. I did not benchmark closed APIs, so I'm not claiming open models are more accurate. My claim is about privacy, cost and control.

Honest limits: this is a hackathon prototype, not a certified billing or compliance system. The local database is not encrypted by the app. OCR and extraction can miss or misread things, so staff must verify every suggestion. I used only fictional data.

AI Assistance

Built with assistance from Claude and Codex.

🌼🍃Flâner: Small steps, Bigger days— Let the Ordinary Lead You Somewhere New.

Shristi Sharma — Sat, 10 Oct 2026 23:02:06 +0000

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

What I Built

Flâner (to wander without hurry, and notice the little things along the way) is a gentle AI companion that helps you take one small step out of the house, then gets out of the way.

Most apps want more of your attention. Flâner is built to want less of it. You talk to it for about a minute, it hands you a small plan, and then it tells you to put your phone away.

Where the idea came from

The theme was Touch Grass, and the more I thought about it, the more it described something I see everywhere. Our homes are comfortable and our phones are endlessly interesting, so we stay in. Slowly we stop noticing what's outside: the street, the light, the small shop around the corner. And the less we go out, the less we explore.

People stay in for many different reasons. Some are simply comfortable. Some find going out a hassle. Some dislike it, and some feel uneasy about it. Whatever the reason, the hardest part is almost always the first step, and "go outside more" is too big and vague to act on.

What helps is a plan. A plan turns a vague wish into a short list, and ticking a box gives a small, real sense of achievement. So Flâner keeps the outing small enough to finish: a checklist for an outing. The reward comes from the real world, not from the app, which is why there are no points or streaks.

The second half of the idea is the reflection. When you come back, Flâner asks what you saw, enjoyed and noticed. Having to remember those details trains you to look for them next time. My hope is that, over time, your attention drifts from the phone to your surroundings.

How it works

Pick a door. I have somewhere to go (groceries, errands, college), I want to explore (a walk, your neighbourhood, some nature), or I need a little nudge (for when you feel stuck).
Get a plan. An open-weight model turns your task into a short, editable checklist: before leaving, getting there, the task itself, coming home. Groceries get your own shopping list word for word. Errands get "check opening hours" and "what to bring". Walks get optional "notice along the way" prompts.
Go. A calm "The world is waiting" screen. No chat, no GPS, no timer. The plan is already on your device as a checklist.
Look back. When you return, Flâner asks what you saw, enjoyed and noticed. Recalling small details is meant to build observation skills. A second model then writes a short, specific acknowledgement.

Who it's for: people who find the first step the hardest part (a grocery run they keep postponing, a walk they never start), and anyone who wants to notice more of the world around them. There are no XP, streaks or leaderboards, staying home is treated as okay, and partial progress counts.

I tried to design against the usual engagement loop. Reflection notes are only stored if you choose Save this moment, and the dashboard is a private record of getting out, not a score.

I took it outside

I needed groceries and had put it off for three days, half-tempted to just order online. I really didn't feel like going. Before leaving, I typed what I needed to buy into Flâner, so my plan already had my list in it. That helped more than I expected: at the shop I didn't have to stop and think about what I'd forgotten. I knew exactly what I was looking for and found the things faster.

The first steps in the checklist (freshen up, get dressed) were what got me moving. I had a bath, got dressed, went to the shop and came back feeling prepared and glad I'd gone. It was a small, ordinary errand, and that's the point. (I used a test account, which I've since deleted.)

Demo

Live app: https://flaner-twp3.onrender.com/

You need an internet connection to use it.

It runs on a free Render instance, so the first visit after a quiet period can take up to a minute to wake up. Sign up with any email to try it.

Code

View the code on GitHub

How I Built It

Stack: vanilla HTML/CSS/JS frontend (no framework, no build step), a Node and Express backend, Supabase for login and data. Everything is deployed as one web service on Render.

Browser ──► Express server ──► plan model       (open-weight gpt-oss-20b on Groq)
   │             │
   │             └──────────► reflection model  (swappable; Gemini in my demo)
   └── Supabase: login, profiles, saved outings (row-level security)

The open-source AI at the core

Plan model: openai/gpt-oss-20b, an open-weight model, served through Groq's OpenAI-compatible API. It does the main work. A system prompt tells it to return only JSON, and the server then extracts it, validates the shape, trims lengths and drops unknown fields. If the model fails, a built-in plan takes over, so the user never sees a broken screen.
Prompts as the "agent's behaviour." The rules live in two plain-text prompts in the repo: be specific to the task, never invent a park, shop, route or opening time, treat safety worries as real, and never shame. Changing how the companion behaves means editing text, not retraining.
Any model, three lines. The server talks to any OpenAI-compatible endpoint, so LLM_BASE_URL, LLM_API_KEY and LLM_MODEL switch between Groq, a local Ollama model, Hugging Face, DeepSeek and others.
A second model for the closing reflection. Each outing makes two AI calls. I split them across two providers so one provider's limits can never block the app. In my demo the reflection uses Gemini (gemini-3.5-flash-lite). That one is not open-weight. It only writes a few kind sentences, and REFLECT_PROVIDER=off removes it, or it can point at any open model.

LLM_MODEL=openai/gpt-oss-20b
REFLECT_MODEL=gemini-3.5-flash-lite

Things that went wrong, and what I did

Hugging Face returned HTTP 402 ("no remaining credits") when I first used it for the reflection. Because the model is a setting rather than hard-coded, I switched providers by changing configuration.
The bottom buttons and tab bar sat off-screen until you scrolled to the end of a page. A container's overflow:hidden stopped them pinning, and switching it to overflow:clip fixed it.

Limitations

Flâner needs an internet connection. Sign-in, building a plan, the reflection and saving all go through Supabase and the AI models, so the app does not work offline. The live demo also runs on a free Render instance that sleeps when it's quiet, so the first visit can be slow.
The model doesn't know where you are. It never names real places. You supply any you want to mention.
The reflection model isn't open-weight. Only the closing acknowledgement uses Gemini, and it can be switched off.

Privacy and your data

What	Where it goes	Kept?
Email and password	Supabase sign-in.	For your account
Name, step-size preference, optional "about me" note	Supabase	Until you delete it
A record of each finished outing: the type (e.g. "Got groceries"), how it felt, minutes outside, a place you name, and the date and time	Supabase, readable only by you	Yes. Saved when you finish (Done for today, Plan another outing or Save this moment)
Reflection notes (what you saw, enjoyed, noticed, expected, happened, remember)	Supabase, only if you tap "Save this moment"	Only if you save
What you type when building a plan or reflection (details, shopping items, notes)	Sent to the AI models (Groq for plans, Gemini for the closing reflection) to write the reply	Not saved by my server or in my database, except notes you choose to save
The plan itself (the checklist the AI writes)	On your own device only	Until you finish or clear it. It is not saved in my database

Outings you start but don't finish are never saved to the database.

Why Does Open Innovation Matter?

I'll be specific about what I did and didn't prove.

Swapping and control. When one provider stopped working, I changed configuration and carried on. The companion's behaviour lives in prompts in the repo that anyone can read and edit. With a single closed API, a pricing change or a limit would have stopped the whole product.
Privacy. What people write about why going out feels hard is personal, and many wouldn't want it sent to a company's server. Because the plan model is open-weight, the same code is designed to run it on the user's own machine through Ollama, so that text never has to leave their laptop. My live demo doesn't work that way: it uses Groq to host the open weights and a hosted Gemini model for the closing reflection, so text goes to those providers. I haven't run the fully local setup in production.
A plan that stays available. The generated checklist is kept on the user's device, so once it has loaded, it doesn't need another AI request to be viewed. The current app still needs an internet connection for sign-in and generating new plans; a fully offline version would need local model inference and offline data handling, which I haven't implemented yet.
Right-sized AI. Turning a short description into a checklist doesn't need the biggest model. A 20B open-weight model is enough, and that keeps it cheap and laptop-sized.
Cost. There's no licence fee for the open model. Hosting and API calls still cost money beyond free tiers.
What I didn't do. I haven't benchmarked this against a closed model, so I can't claim it beats one on quality. I also haven't fine-tuned anything. The "what I feared, what happened" reflections could become a training set one day, but only with consent.

AI Assistance

Built with assistance from Claude and ChatGPT.

Prize Categories

Best Use of Render: the whole app runs as a single Render web service.

DEV Community: Shristi Sharma

👻🎬Miedocuentista: a fully local AI that turns your photos into haunted stories, film scripts and novels📜🪶

What I Built

Demo

Code

shristi005 / Miedocuentista

Feed the spirits one frame at a time. They write the film, the script, the novel.

👻 Miedocuentista

Table of contents

How I Built It

Challenges I Hit (and Why I Think They Happen)

Future Improvements

How It Can Be Used

Why Does Open Innovation Matter?

The Spirit of It

ClaimReady: a local-AI claims workbench for hospital front desks

What I Built

Demo

Code

shristi005 / ClaimReady

ClaimReady

The problem

Who it is for

Features

Claim Check — review a claim before submission

How I Built It

Why Does Open Innovation Matter?

AI Assistance

🌼🍃Flâner: Small steps, Bigger days— Let the Ordinary Lead You Somewhere New.

What I Built

Where the idea came from

I took it outside

Demo

Code

How I Built It

Limitations

Privacy and your data

Why Does Open Innovation Matter?

AI Assistance

Prize Categories