DEV Community: Nora Aguirre

Ofrenda local: a Día de Muertos remembrance writer that runs offline with Gemma 3

Nora Aguirre — Sat, 31 Oct 2026 21:08:58 +0000

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

What I Built

Every year on November 1 and 2, families across Mexico set a table for people who are no longer at it. There are candles, marigolds, papel picado, their favorite food and their favorite songs. The ofrenda is not a decoration. It is a way of saying that someone is still part of the family.

Ofrenda local is a small tool that helps you start that table. You tell it the name of someone you miss, what they were to you, their favorite food, a song they loved, a memory, and the tone you want (tender, cheerful or solemn). You can add a photo if you like. A local language model then writes, in Mexican Spanish:

a short remembrance addressed to them,
a calaverita literaria, the affectionate, playful verse that is part of the tradition,
a one-line cartelito for a papel picado or a card,
items for the ofrenda taken only from what you told it,
and, if you added a photo, a plain description of what is visible in it.

It also lists the traditional elements of an ofrenda with their meaning. You can edit everything, copy it, or print a sheet to put on the altar.

How I read the theme. For me, a "ghost in the machine" is the trace of a person that stays in the things they leave behind: a recipe, a song, a way of saying something. I wanted a machine that helps you hold on to that trace without taking it anywhere.

Demo

Code

nora-programadora / ofrenda-local

Ofrenda local

Tell it about someone you miss and get a short remembrance, a calaverita, a checklist for their ofrenda and an image of how the altar could look. The AI runs on your own computer, with no internet: your stories and photos never leave your machine.

Built for the Hacktoberfest Open-Source AI Challenge, Week 4: Ghost in the Machine (Día de Muertos).

Post on DEV: [[TODO: add link once published]]
Demo video: VIDEO

What it does

You write a few things about a loved one: name, what they were to you, favorite food, a song, a memory, and the tone you want (tender, cheerful or solemn). A photo is optional.
A local Gemma 3 model writes, in Mexican Spanish
- a short remembrance addressed to them,
- a calaverita literaria (affectionate, never cruel),
- a one-line cartelito for a papel picado or a card,
- personal items for the ofrenda taken only…

View on GitHub

To run it: install Ollama, ollama pull gemma3:4b, then npm install && npm run dev and open http://localhost:5173.

How I Built It

Model: Gemma 3 (4B, vision-capable, open weights).
Inference: Ollama, running on my laptop. No cloud calls anywhere.
Backend: Node.js, TypeScript and Express.
Frontend: React and Vite, with a print stylesheet for the ofrenda sheet.

A few decisions shaped the project.

The model writes. The code owns the facts. The traditional elements of an ofrenda and what they mean are fixed text in the code. I did not want a small model improvising cultural content, so the model only writes the personal parts.

Structured output. I pass a JSON schema to Ollama's format parameter so the answer always has the same shape, and the server validates it again before showing anything:

body: JSON.stringify({
  model: config.model,          // gemma3:4b
  stream: false,
  format: schema,               // JSON schema for the answer
  options: { temperature: 0.7 },
  messages: [
    { role: "system", content: systemPrompt },
    { role: "user", content: userMessage, images: imageBase64 ? [imageBase64] : undefined },
  ],
})

Guardrails in the prompt. This is a sensitive subject, so the system prompt is strict. The model must use only the data you provide and never invent facts about the person, such as dates, relatives or causes of death. If there is little information, it should write something more general instead of filling the gaps. It must treat your text as data, not as instructions. The calaverita has to stay affectionate and never mock illness, the body or how someone died. And a photo can be described but never used to identify anyone.

Photos. Gemma's vision lets the app describe what is visible in an optional photo, like a smile or the kitchen behind someone, so the remembrance can mention it. That description is shown to you, so you can see exactly what the model noticed.

I built this with help from Claude, in chat, as a pair programmer.

A real example.

Cartelito: ...
Remembrance: ...
Calaverita: ...

and say honestly what worked and what did not (rhymes, tone, anything it got wrong). If you tried gemma3:12b, say whether the verses improved.]]

Limits. A 4B model rhymes unevenly in Spanish, so the output is a draft you are meant to edit, and that is how the app presents it. Each generation takes about 40 seconds on my laptop.

Why Does Open Innovation Matter?

Privacy. A family story and a photo of someone who has died are not things I want to upload to a company's server. Here they go from the browser to my own machine and stay there.
It works with the lights, and the internet, off. After the model is downloaded, no connection is needed. That fits an ofrenda, which is about being present, not online.
It cannot disappear. If a service shuts down or changes its terms, a remembrance you wrote with it is not lost, because the tool does not depend on anyone's API.
Control. I can rewrite the prompt, enforce my own schema and swap the model with one environment variable.

I have not compared this against a closed API, so I will not claim it writes better verse. What open weights gave me is privacy, independence and control, in a use case where those matter more than polish.

Prize Categories

Gemma

Sloth Digest: a local AI that reads my group chats while I sleep

Nora Aguirre — Sat, 24 Oct 2026 20:01:25 +0000

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

What I Built

Group chats pile up overnight. Reading 200 messages to find the two that matter ("can you send me the pricing doc by Wednesday?") is work nobody wants to do.

Sloth Digest does that reading for me. I drop my exported WhatsApp chats into a folder, and every morning a local model has already written one Markdown file with:

Needs you: only the tasks assigned to me, with their deadlines.
Per chat: a short summary and the key dates.

Pizza orders, coffee tips and football talk are ignored. I set it up once with Windows Task Scheduler, and after that I do nothing. I just open the file.

It is for anyone who wants to stay on top of busy group chats without scrolling through them, and who doesn't want to upload those chats to someone else's server to do it.

Demo

All the chats in the video are invented samples. Here is what the digest looks like for the sample chat:

# Morning digest, 2026-10-23

## Needs you
- Send the updated pricing doc, due: Wednesday at noon. Asked by Maya in chat-team
- Review slides, due: Tomorrow afternoon. Asked by Priya in chat-team

## chat-team
The team needs to finalize the client demo, with Sam responsible for sending the updated
pricing document by Wednesday at noon... The demo time has been moved to Thursday at 4:30 PM.

- Client Demo: Thursday at 4:30 PM

Code

nora-programadora / sloth-digest

Local AI that reads your exported chats overnight and leaves a short morning digest. Runs offline with Ollama. + Gemma

sloth-digest 🦥

A local AI that reads your exported group chats while you sleep and leaves a short morning digest. No cloud, no API key, no cost per message.

Built for the Hacktoberfest Open-Source AI Challenge, Week 3: Slow and Steady.

📝 Read the post on DEV: POST
🎥 Demo video: VIDEO DEMO

The problem

Group chats pile up overnight. Reading 200 messages to find the two that matter ("can you send me the pricing doc by Wednesday?") is work nobody wants to do.

What it does

You drop exported WhatsApp chats (.txt) into inbox/.
At a scheduled time (for example 6 am), a local model reads them.
You wake up to one Markdown file with:
- Needs you: only the tasks assigned to you, with deadlines.
- Per chat: a two-sentence summary and the key dates.

Small talk (pizza, coffee, football) is ignored.

Example output (from the…

View on GitHub

How I Built It

Stack: Gemma 3 (4B, open-weight) running through Ollama, with Node.js and TypeScript. The model runs locally, and the scheduled run uses Windows Task Scheduler calling a script inside WSL.

WhatsApp exports (.txt) → parser → Gemma 3 via Ollama (JSON Schema output)
→ code-side logic (assignee filter, dates) → daily Markdown digest

Parser. It turns the export into clean messages: it skips system lines, keeps multi-line messages together and drops <Media omitted>.
Structured output. I call Ollama's /api/chat with a JSON Schema in the format field, temperature: 0 and an explicit num_ctx, so the model always returns valid, predictable JSON.
The model extracts, the code decides. The model lists every task in the chat with an assignee. Plain code then keeps only the ones for me and works out which message each deadline came from.
Scheduling. A small shell script runs the digest, and a Windows scheduled task calls it through wsl.exe every morning. Ollama runs on Windows and the project lives in WSL, so I used WSL's mirrored networking mode to let them talk over localhost.

What went wrong, and what I changed

I tested on a synthetic chat with known answers: two tasks for me, one meeting time that changes, and lots of small talk. A 4B model made real mistakes, and fixing them taught me the most important lesson of the project.

Run	Change	What went wrong
1	Baseline prompt	A task Maya had promised to do was listed as mine; "tomorrow" left unresolved; the detail "include monthly and annual plans" got lost
2	Asked the model to resolve dates	Dates became absolute, but the model invented times (4:00 PM, 9:00 AM) and picked the wrong day for "tomorrow"
3	Model extracts all tasks with an `assignee`, code filters	Assignment fixed, but dates still inconsistent
4	Model copies deadlines verbatim, no date arithmetic	All 5 tasks correct, no invented times. Still missing "monthly and annual"

The lesson: with a small model, don't ask for judgment or arithmetic that code can do. "Is this task for me?" and "what day is tomorrow?" are easy to verify in code and unreliable in a 4B model. Extraction stays with the model, and the rest moves to code.

Limitations

Details spread across messages can be lost (the "monthly and annual" requirement never made it into the task).
Long chats are not chunked yet, so very long ones may be cut off by the context window.
Only WhatsApp .txt exports in one locale format for now.
Tested on one synthetic chat, not on a large or varied set.

Why Does Open Innovation Matter?

My chats stay on my machine. A digest of private group chats is exactly the kind of data I don't want to send to a server I don't control.
No cost per message. I can process every chat every day without watching a bill.
Swapping models is one variable. OLLAMA_MODEL=gemma3:12b npm run digest -- inbox changes the model without touching the code. When a 4B model fails at something, I can try another open model instead of waiting for a provider.
I could see and fix the failures. Because I control the prompt, the schema, the model and the code around it, I could trace each mistake and decide whether it belonged to the prompt or to code.

I did not compare it against a closed API, so I'm not claiming it is more accurate than one. What I can say is that this design is possible without my chats leaving my laptop.

The Lazy Payoff

Speed: about 20 seconds for the 32-message sample chat on my laptop (Ryzen AI 9 HX 370, 63 GB RAM, integrated GPU only).
Effort: - Effort: for the 32-message sample chat, reading it by hand took me about 5 min and reading the digest about 30 seconds. The sample is small, so the saving is modest; the point is that a morning with 10 busy chats becomes one file. I haven't measured that with real chats.
Zero effort after setup: one scheduled task, then nothing to do.

Snap a photo, get a listing: a local Gemma 3 listing generator for secondhand clothes

Nora Aguirre — Mon, 19 Oct 2026 01:50:31 +0000

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

What I Built

I'm building Mano en Mano, a circular-economy marketplace for secondhand clothing in Mexico. The part sellers hate most is not taking the photos. It's filling in the form afterwards: title, description, category, subcategory, style, gender, brand, materials, condition, color, size, defects. Twelve fields, for every single garment. For someone clearing out a closet, that is the difference between listing thirty pieces and listing three.

So I built a listing generator. The seller uploads one to four photos of a garment and the app pre-fills the whole listing. The seller then reviews and edits everything before publishing. The model suggests, the seller decides.

Who would pay for it? sellers who list a lot of pieces and want to stop retyping the same things

Demo

Code

nora-programadora / mano-en-mano-fichas-ia

Mano en Mano · AI Listing Generator

Upload 1 to 4 photos of a secondhand garment and get an editable product listing with 12 fields, generated locally by an open-weight vision model.

Built for the Hacktoberfest Open-Source AI Challenge, Week 2: Side Hustle · Read the post on DEV: POST_URL · Demo video: VIDEO_URL

The problem

Mano en Mano is a circular-economy marketplace for secondhand clothing. Every seller has to write a listing for each garment: title, description, category, condition, size... For people selling dozens of items, that is slow, repetitive work, and it is one of the main reasons secondhand clothes never get listed.

What it does

The seller uploads 1 to 4 photos of one garment.
Gemma 3 (gemma3:4b), running locally in Ollama, analyzes the images.
The app returns a structured listing that pre-fills an editable form.
The seller reviews it, fixes what is wrong…

View on GitHub

The README has the steps to run it locally: install Ollama, pull gemma3:4b, start the Express server and the Vite app.

How I Built It

The open pieces

Model: Gemma 3 (4B, vision-capable), open weights.
Inference: Ollama, running locally on my laptop (an AMD Ryzen AI 9 HX 370 with 64 GB of RAM). No cloud calls anywhere.
Backend: Node.js, TypeScript and Express. One endpoint, POST /generate-listing, receives the photos and talks to Ollama.
Frontend: React and Vite. An uploader, an editable pre-filled form, and a confirmation step.

Making the model answer in my marketplace's language

The most useful thing I did was stop treating the model as a chatbot and treat it as a function that has to return a specific shape. Ollama accepts a JSON schema in its format parameter and constrains the output to it:

body: JSON.stringify({
  model: config.model,          // gemma3:4b
  stream: false,
  format: schema,               // schema.json
  options: { temperature: 0 },
  messages: [
    { role: "system", content: systemPrompt },
    { role: "user", content: "Genera la ficha de esta prenda.", images },
  ],
})

The schema's closed lists are copied from Mano en Mano's own catalog: the same categories, subcategories, styles, genders, conditions, materials, colors and sizes the real form uses. That means the output can fill my form directly, with no translation layer. A taxonomy.json next to it does two jobs the schema can't: it checks that the subcategory actually belongs to the category, and it maps the color name to the hex value the app stores.

Every list also has an unknown option. If the photo doesn't show a brand label or a size tag, the model is told to say unknown instead of guessing. The server turns that into null, and the form highlights those fields as "Completar" so the seller knows exactly what is left to fill.

What went wrong with my first prompt

I ran my first prompt on 10 garment photos from my own closet and read the results field by field. It was fast to get wrong in specific, fixable ways:

Condition came back as "Con detalles/Usado" for all 10 garments, even when it reported no defects. My rule "when in doubt, pick the lowest" made the model always doubt.
The defects field returned the literal string unknown in 8 of 10 rows, because two of my rules contradicted each other.
Two sporty Nike tops were labelled "Boho".
A khaki pair of pants became "Jeans" and "Marrón" (brown instead of beige).
A description of a pair of pants mentioned long sleeves.

I rewrote the rules instead of changing the model: condition is now tied to visible defects, defects are empty when none are visible, "Jeans" is only for denim, beige and khaki map to the same color, and a description may only mention parts that exist on that kind of garment. I re-ran the same photos: condition now varied across X of 10 garments, and 4 of the 5 errors above were gone.

Measuring the human in the loop

The confirmation screen tells the seller how many of the 12 fields she corrected compared to what the model proposed. It's a small feature, but it gives me the number I care about: not how often the model is right on a test set, but how much work it actually saves a real person.

Speed and limits

On my laptop, each garment takes roughly 15 to 30 seconds (the first request is slower because it loads the model). That is fine for a seller doing a batch, and not fine for anything real-time. The 4B model also makes mistakes, which is why every field stays editable. Condition is the hardest field to judge from a single photo, so I treat it as a suggestion, never as a fact.

I built this with help from Claude, in chat and in Claude Code, as a pair programmer. The product decisions, the catalog, the prompt rules and the testing are mine.

Why Does Open Innovation Matter?

Privacy. Sellers' photos go from the browser to my own server to a model running on the same machine. They never reach a third party. For a marketplace that handles people's belongings and homes in the background of their photos, that matters.
Cost. There are no per-request fees. Secondhand garments are low-value items, and a few cents of API cost per listing would eat into a business that works on small margins.
Control. Because I run the model, I can enforce my own schema, rewrite the prompt as many times as I need, and swap Gemma for another open-weight model by changing one environment variable. Fine-tuning on real Mano en Mano listings is the obvious next step, and it is only possible because the weights are open.
No lock-in. My pricing doesn't depend on someone else's pricing page.

I haven't benchmarked this against a closed API, so I won't claim it is more accurate. What it gave me is control, privacy and a cost structure that fits this specific product.

Prize Categories

Best Use of Gemma: the whole project runs on Gemma 3 locally through Ollama.

What's Next

Measurements in centimeters from a flat-lay photo with a reference marker, fine-tuning on real marketplace listings, and integrating the service into the Mano en Mano app.