DEV Community: Abbey 🌠

Ghost in the Repo: Resurrecting Abandoned Code with a Local Open Model

Abbey 🌠 — Sat, 31 Oct 2026 15:42:39 +0000

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

What I Built

README Resurrection is a command-line tool that raises abandoned repositories from the dead. Point it at a repo with no documentation and it writes a README, setup instructions, an architecture overview and a contributing guide, using a local open-weight model. Then it checks its own work and flags anything it couldn't verify.

For the theme, I took "ghost in the machine" literally. An abandoned project is a ghost: the code is still there and still runs, but the person who understood it is gone. Documentation is how the living remember the dead, so I wanted a tool that goes through a forgotten repo and writes down what it was. Before it generates anything, it prints a "Resurrection report" that says whether the repo is alive, dormant or dead, and how much documentation it's missing.

Code

AbbeyIT / readme-resurrection

A tool for generating README.md files for software repositories using various facts about the repository.

How I Built It

The open stack: Ollama running Qwen2.5-coder:7b locally, with a small Python CLI (typer, rich, httpx) around it. There are no API keys and no hosted models in the product. I developed it on a Windows laptop with no GPU, so the model runs 100% on CPU.

The lesson that shaped the design: a small model asked to "write a README" invents things. My first generated README had a Usage section with command-line arguments that don't exist. Its Architecture document claimed modules imported each other when they didn't. The model wasn't broken; my facts had gaps, and it filled them with plausible guesses.

So the tool does as little as possible with the model:

Plain code collects the facts: file tree, languages, dependencies, entry points, scripts, license type (detected from the license text), and the real Python import graph read with the ast module.
The model summarizes key files, with results cached by content hash.
The model writes each document from those facts only, with a list of verified commands it's allowed to use and a rule to write unknown rather than guess.
Plain code verifies the output. Every file path, command and "X imports Y" claim is checked against the repo, and anything that doesn't hold up goes into a ## Needs review section.

Each time a document was wrong, the fix was never a cleverer prompt. It was a better fact, extracted by code: the CLI entry point from pyproject.toml, the license type from the license text, the optional [dev] dependencies, the import graph.

How the code got written:
I tried driving the build with opencode pointed at a local Ollama model, but on CPU it ran at about 0.3 tokens per second and the 7B model printed its tool call as plain text instead of executing it, so no files were created. I then built the project in small steps with a hosted AI assistant helping draft the code, and I ran, tested and committed each step myself.

Why Does Open Innovation Matter?

The people who most need this tool are working with code they can't upload. Legacy and proprietary repositories are exactly where documentation is missing, and exactly where sending the source to a closed API isn't an option. With an open-weight model running through Ollama:

The code never leaves the machine. That's the difference between a tool you could use at work and one you couldn't.
It works offline. Once the model is pulled, no network is needed (except to clone a repo).
The model is swappable. --model takes any Ollama model, and all model access is in one small file. When I found my 7B model was slow on CPU, switching to a smaller one was a flag, not a rewrite.
It costs nothing to run. No keys, no per-token billing, so it's practical to re-run it on a whole folder of old repos.
Nothing is locked in. There's no service that can change pricing, retire a model, or disappear. That seemed right for a tool whose whole point is rescuing things that were abandoned.

Open models also made the hard part easier to see. Because I could run the same small model locally and watch exactly where it went wrong, I learned that the answer was grounding it in facts, and the same approach would help with larger models too.

The Spirit of It

I pointed the tool at GitHub's oldest demo repository, octocat/Hello-World, to see how it describes a ghost:

Condition      DEAD - last commit 2012-03-06, 14 years, 8 months (5,351 days) ago
README         stub (README, under 500 bytes)
SETUP          missing
ARCHITECTURE   missing
CONTRIBUTING   missing
Revival score  100/100  ##########

This is from my own repo:

Sloth Tidy: A Local AI That Cleans Your Messy Folders While You Nap

Abbey 🌠 — Sat, 24 Oct 2026 16:12:50 +0000

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

What I Built

Sloth Tidy is a command-line tool that cleans up a messy folder (think Downloads) using an open-weight model running on my own machine.

You point it at a folder. For each file it reads a short snippet, then proposes a category, a clean filename, and a destination: scan0012.pdf becomes Invoices/2026/2026-10-31_meralco-electricity-bill.pdf. Nothing moves until you review a dry-run plan and apply it, and every move can be undone with one command. There's also a watch mode that files new arrivals in the background.

It's for anyone who has a folder full of scan0012.pdf, Document (3).docx, and Screenshot 2026-10-03.png and keeps putting off the cleanup. The sloth move is to run it once and walk away.

Code

AbbeyIT / sloth-tidy

Sloth Tidy

Point it at a messy folder; a local open-weight model proposes where everything belongs.

Why local and open

Sloth Tidy sends readable file snippets to Ollama on your machine by default. After you pull a model, it can run without internet access, hosted model APIs, or API keys; file contents stay on your machine. Choose another Ollama model with SLOTH_MODEL, and steer its decisions with rules.yaml. A remote Ollama server is possible only when you explicitly pass --allow-remote.

Requirements and setup

Node.js 20 or newer
Ollama installed and running
A pulled model; the default is qwen2.5:7b
Model weights are not included and are subject to their own licenses.

ollama pull qwen2.5:7b
npm install
npm run build
npm test

Quick start with the demo

Generate the 30-file demo, copy it, and plan against the copy. The plan is written beside the copy so it is not…

View on GitHub

MIT licensed. TypeScript, Node 20+, and Ollama.

How I Built It

The open parts at runtime: Ollama serves qwen2.5:7b locally. The tool talks to it over plain HTTP on localhost, with no API keys and no hosted services. The model name is one environment variable, SLOTH_MODEL.

How I built the project: I wrote a SPEC.md and built it in seven milestones with OpenAI Codex, committing after each one. The runtime doesn't depend on Codex, only the building did. Dependencies are small: commander, zod, pdf-parse, mammoth, and vitest.

The main lesson is that a small local model needs a tight leash. My first version asked the model for a folder and a filename, and the results were bad:

Reasons came back in Chinese, because Qwen drifted languages.
Folder names were garbage, like Invoices/2026-10-20-09-02-34-Meralco_Electricity_Billpdfgz-invoices-2026-10-20.
Timestamps were invented.
Files kept their original names.

So I changed the design so the model decides as little as possible:

The model picks a category from a fixed list (enforced with a JSON schema) and writes a 2 to 6 word description. It never writes a path.
Code builds the folder and filename and keeps the original extension.
Dates must be verified. A date the model returns has to actually appear in the file's text, and the checker understands things like "01–31 October 2026". Otherwise the file's modified date is used.
Output is validated. Non-English text, invalid categories, and bad JSON are rejected and retried once, then the file is left in place.
Files with no readable content (images, installers) never reach the model. They're filed by extension. On my demo folder that was 10 of 30 files, so they cost nothing.

Safety is designed in: dry-run by default, never overwrite or delete, destinations can't escape the root folder, files that changed since planning are skipped, and every batch goes in an undo log. Watch mode only moves files with an explicit --apply flag and only above a confidence threshold. Anything it isn't sure about waits in a pending plan.

A rules.yaml file steers it without touching code: allowed folders, files to never touch, and overrides like "worksheet*.docx always goes to School".

Why Does Open Innovation Matter?

A Downloads folder is some of the most personal data on a computer: invoices, school forms, lease summaries, job applications. Sending a stranger's server the first lines of every file to sort them is a hard sell. With a local open-weight model, the file contents never leave the machine, and it works offline once the model is pulled.

Three more things open made possible:

Cost. My plan run takes several minutes, which is fine when the model is free. With a metered API, "run it on every new file in the background" becomes a bill.
Swappability. One environment variable changes the model, and I could compare two models on the same folder with no new accounts.
Control. Because the model runs locally with schema-enforced output, I could build guardrails around it and test them with a mocked model, 71 tests in total.

To be fair to closed models: a larger hosted model would probably be more consistent on borderline files. In my runs, the lease summary landed in Personal once and in Work another time, even at temperature 0. That's why rules.yaml overrides exist. For this particular job, I'd take a slightly less consistent model that never sees my files.

Payload Doctor: a private, offline AI that explains failing integration payloads

Abbey 🌠 — Mon, 19 Oct 2026 10:07:59 +0000

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

What I Built

Payload Doctor is a small tool for integration developers. You paste a failing JSON or XML payload and the error it produced, and a local AI model explains what went wrong and suggests a fix.

I work with enterprise integrations day to day, and one of the most common time sinks is staring at a rejected payload: a wrong date format, a missing field, a namespace mismatch, an expired token. The obvious shortcut is pasting it into a cloud chatbot, but integration payloads contain business data (customer names, emails, order details, credentials), and that data usually isn't yours to send to a third party.

The people who would pay for this are freelance integration consultants and small dev shops that work with client data and can't, or won't, paste it into a cloud AI. Payload Doctor gives them the speed of an AI assistant without the data leaving their laptop.

Code

AbbeyIT / payload-doctor

Payload Doctor

A local, private assistant for integration developers. Paste a failing JSON/XML payload and its error, and an open-weight model running on your own machine explains what went wrong and how to fix it.

Runs on your laptop through Ollama. No cloud API, no per-request cost, works offline.
Emails, tokens, IPs, and long IDs are masked in code before the model sees anything. The UI shows exactly what was sent.
The server binds to 127.0.0.1 only.

Quick start

# 1. Install Ollama (https://ollama.com), then pull a model
ollama pull qwen3.5:4b      # or a smaller one: llama3.2:3b

# 2. Run the app
npm install
npm start                            # http://127.0.0.1:3000

Options (environment variables): MODEL (default qwen3.5:4b), PORT (default 3000), OLLAMA_HOST (default http://127.0.0.1:11434).

How it works

src/redact.ts masks secrets and personal data, using the same placeholder for the same value ([EMAIL_1]).
src/prompt.ts builds the prompt and adds…

View on GitHub

How I Built It

Model: qwen3.5:4b, an open-weight model, running locally through Ollama.
App: Node.js and TypeScript with Express, and a single plain HTML page for the UI.
No cloud calls: the server talks only to the local Ollama API and binds to 127.0.0.1, so it isn't reachable from other machines.

The model is only part of what makes it work. Most of the reliability comes from the code around it:

Redaction before the model. Emails, tokens, JWTs, IP addresses, phone numbers, and long opaque IDs are masked in code before the model sees anything. The same value always gets the same placeholder ([EMAIL_1]), so the model can still reason about it. The UI shows exactly what was sent.
A deterministic parser check. Small models are unreliable at spotting a missing comma. So the code runs JSON.parse first and tells the model whether the payload is valid.
Structured, validated output. The model replies in JSON, which I validate with zod. If the reply is unusable, the app retries once with the validation error.
A small eval script. npm run eval runs a file of test cases through the model and reports PASS or FAIL, so I can change the prompt or the model and see what happens.

Testing it

I wrote 10 test cases for problems I see often in integration work, all with fake data: a wrong date format with a missing required field, a trailing comma in JSON, a SOAP namespace mismatch, an expired auth token, a string sent where an integer was expected, a payload that's too large, a missing Content-Type header, an upstream gateway timeout, a rate limit, and malformed URL-encoded form data.

Results: 10 of 10 passed on qwen3.5:4b, each on the first attempt with no retry needed. Answers took 26 to 42 seconds each on my laptop.

Where the small model struggled: the answers were right from the start, but my first run was far too slow. The gateway timeout case took 179 seconds, the expired token case took 107, and the SOAP namespace case hit my 180-second timeout and failed. The model was spending most of that time on hidden "thinking" before it replied. Because the model is open and runs locally, I could change that directly: I turned off its thinking mode and raised the request timeout. The same cases then ran in about 30 seconds, and the SOAP case passed.

Known limits:

The eval is a keyword check. It confirms that the answer mentions the right field or concept, not that every word of the fix is correct.
Redaction is pattern-based, so it won't catch things like names or account numbers.
Treat the answer as a second opinion, not a verdict.

Why Does Open Innovation Matter?

Because of what this tool is