Repo Séance 👻 — Giving Abandoned Repositories a Second Life

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

What I Built

Every abandoned repository has a story.

Some projects stop after a single commit. Others contain months of development, unfinished features, confusing dependencies, and code that nobody has touched in years. When the original developer disappears, the repository is left behind — almost like a digital ghost.

That's the idea behind Repo Séance.

Repo Séance is a local-first AI-powered tool that helps developers understand abandoned or unfamiliar codebases. Instead of simply generating a summary, it lets you interact with a repository as if you were interviewing its past.

You can ask questions such as:

• What was this project originally trying to achieve?
• Which parts of the application were actively developed?
• What was the last major change?
• Which modules depend on this file?
• What should I work on first to bring this project back to life?

The tool analyzes source code, project structure, dependencies, and Git history to build an evidence-backed picture of the repository.

I interpreted Ghost in the Machine as the digital remains of software projects: code that still exists, even when the people and context behind it are gone.

The goal is simple: help developers understand what was left behind and make it easier to continue the work.

The project is designed for local execution, so the demo can also showcase the application running on a developer's machine.

Code

🔗 GitHub Repository:

ansh-rajpoot / repo-ghost

Repo Séance

Every repository leaves a ghost. Some still have something to say.

Repo Séance is a local archaeological tool for forgotten software. You open a ZIP or a checkout the backend can already see. It reads the tree, the git history when one exists, and the Python import graph. Then you question an entity called the Ghost. Every factual claim is tied to a file, a line, or a commit that was actually retrieved. When the record is silent, the ghost says so.

Summon the past. Understand the code. Revive what was forgotten.

What it does

• Cinematic threshold, then a three-pane archive: catacombs, memory topology, and the medium.
• ZIP upload with path-traversal, symlink, size, and secret-filename checks. Uploaded code is never executed.
• Local-directory mode limited to configured roots. The browser cannot send an arbitrary path.
• Git history through the git CLI: hashes, author timestamps with their original offsets, file…

View on GitHub

How I Built It

Repo Séance combines traditional code analysis with local AI inference.

The planned architecture uses:

• React + TypeScript + Vite for the frontend.
• FastAPI + Python for the backend.
• Python AST to inspect Python source files and extract structural information.
• Git history analysis to understand commits and reconstruct the project's development timeline.
• Ollama to run an open-weight language model locally.
• A repository retrieval layer to provide relevant code and history as context for AI-generated answers.

One important design decision was to avoid relying on a hosted AI API. Repository code can contain private implementation details, credentials, or intellectual property. Keeping inference local gives developers greater control over where their code goes.

I also wanted the application to distinguish between verified facts, reasonable inferences, and unknown information. For example, a repository may show that development stopped after a particular commit, but it cannot reliably tell us why the developer stopped working on it.

Repo Séance should never invent that story.

The AI helps interpret the evidence; the repository itself remains the source of truth.

Why Does Open Innovation Matter?

A project like Repo Séance makes much more sense when built with open-source technologies.

Local inference through Ollama and open-weight models makes it possible to experiment with AI without sending an entire repository to an external API. Open-source frameworks also let developers inspect, modify, and extend the system according to their own requirements.